สถาปัตยกรรมที่ดีที่สุดสำหรับแอปพลิเคชัน ASP.NET WebForms

ฉันเขียนพอร์ทัล ASP.NET WebForms สำหรับลูกค้า โครงการมีการพัฒนามากกว่าการวางแผนและโครงสร้างอย่างเหมาะสมตั้งแต่ต้น ดังนั้นรหัสทั้งหมดจะถูกบดเข้าด้วยกันภายในโครงการเดียวกันและไม่มีเลเยอร์ใด ๆ ตอนนี้ไคลเอนต์มีความสุขกับการใช้งานดังนั้นฉันต้องการ refactor รหัสเพื่อที่ฉันจะมั่นใจในการเปิดตัวโครงการ เนื่องจากมีหลายวิธีที่แตกต่างกันในการออกแบบสถาปัตยกรรมฉันต้องการความคิดเห็นเกี่ยวกับวิธีการที่ดีที่สุด

หน้าที่การทำงาน

พอร์ทัลอนุญาตให้ผู้ดูแลระบบกำหนดค่าเทมเพลต HTML "พันธมิตร" อื่น ๆ ที่เกี่ยวข้องจะสามารถแสดงเทมเพลตเหล่านี้ได้โดยการเพิ่มรหัส IFrame ไปยังเว็บไซต์ของพวกเขา ภายในเทมเพลตเหล่านี้ลูกค้าสามารถลงทะเบียนและซื้อผลิตภัณฑ์ API ได้รับการดำเนินการโดยใช้ WCF เพื่อให้ บริษัท ภายนอกสามารถเชื่อมต่อกับระบบได้ ส่วนผู้ดูแลระบบช่วยให้ผู้ดูแลระบบสามารถกำหนดค่าฟังก์ชันการทำงานต่างๆและดูรายงานสำหรับพันธมิตรแต่ละราย ระบบจะส่งใบแจ้งหนี้และอีเมลแจ้งเตือนไปยังลูกค้า

สถาปัตยกรรมปัจจุบัน

ขณะนี้ใช้ EF4 เพื่ออ่าน / เขียนไปยังฐานข้อมูล วัตถุ EF ถูกใช้โดยตรงภายในไฟล์ aspx สิ่งนี้อำนวยความสะดวกในการพัฒนาอย่างรวดเร็วในขณะที่ฉันเขียนไซต์ แต่ก็อาจยอมรับไม่ได้ที่จะทำให้มันเป็นแบบนั้นเพราะมันเชื่อมต่อฐานข้อมูลกับ UI อย่างแน่นหนา ตรรกะทางธุรกิจที่เฉพาะเจาะจงได้รับการเพิ่มลงในคลาสบางส่วนของวัตถุ EF

คำถาม

เป้าหมายของการปรับโครงสร้างใหม่จะทำให้ไซต์สามารถปรับขนาดได้บำรุงรักษาได้ง่ายและปลอดภัย

สถาปัตยกรรมแบบไหนที่ดีที่สุดสำหรับสิ่งนี้? โปรดอธิบายสิ่งที่ควรอยู่ในแต่ละเลเยอร์ไม่ว่าฉันจะใช้รูปแบบของ DTO / POCO / Active Record เป็นต้น
มีวิธีที่แข็งแกร่งในการสร้าง DTO / BOs อัตโนมัติหรือไม่เพื่อให้การปรับปรุงในอนาคตจะง่ายต่อการใช้งานแม้จะมีเลเยอร์เพิ่มเติมหรือไม่
มันจะเป็นประโยชน์ในการแปลงโครงการจาก WebForms เป็น MVC หรือไม่

— คนซ้อน
แหล่งที่มา

ปล่อยก่อนปล่อยบ่อย ฉันขอแนะนำให้ลูกค้าของคุณอาจไม่สนใจมากหากคุณไม่มีปัญหาทางธุรกิจที่จับต้องได้ที่จะนำเสนอ (เช่นมันไม่ปลอดภัย) บางทีคุณควรทำความสะอาดนิดหน่อย (ตรวจสอบให้แน่ใจว่ามันพกพาได้) และปล่อยจากนั้นใช้สิ่งนี้เป็นความคิดริเริ่มระยะยาว - เพื่อแปรเปลี่ยนเป็น MVC หรือสิ่งที่คล้ายกัน

— gahooa

อย่าเปลี่ยนเทคโนโลยีโปรเจคที่ทำงานเป็นเทคโนโลยี xyz ใหม่เพราะมีอยู่แล้วโดยเฉพาะอย่างยิ่งถ้าโปรเจ็กต์ของคุณทำงานได้ดีเหมือนที่เคยเป็นมา ถ้ามันใช้งานได้อย่าทำลายมัน ธุรกิจไม่สนใจรหัส ฟังก์ชั่นคือทุกสิ่งที่สำคัญในตอนท้ายของวัน

— NoChance

ตกลงที่เป็นจริง แต่ความกังวลของฉันคือเมื่อปล่อยมันจะยากที่จะ refactor เพราะความเสี่ยงของการทำลายมันเมื่อเดิมพันสูงขึ้นมาก ดังนั้นเราจะติดกับรหัสที่ไม่สามารถบำรุงรักษาได้และยากกว่าในการดีบัก ฯลฯ ฉันถูกล่อลวงให้เรียนรู้ / แปลงเป็น MVP แต่ดูเหมือนว่าจะทำงานมากเกินไป จนถึงตอนนี้ฉันเพิ่งแปลงเป็น DAL, Domain, เลเยอร์ UI ซึ่งให้ความรู้สึกเป็นระเบียบมากขึ้น แต่ก็ยังช่วยให้ RAD ที่หลีกเลี่ยงไม่ได้ที่จะต้องใช้ในขณะที่โครงการยังเด็ก วันหนึ่งถ้าจำเป็นฉันสามารถขยายเป็น MVP หรือ MVC ฉันคิดว่า - หลังจากฉันมีเวลาเพียงพอที่จะเรียนรู้วิธีการทำงานทั้งหมด

— คนซ้อน

สิ่งที่รู้สึกยุ่งคือ: 1) EF Objects ใน UI (โค้ดที่อยู่เบื้องหลังไฟล์ในเลเยอร์ UI)

— stack man

(2) ตรรกะทางธุรกิจในวัตถุ EF ที่ขยายเพิ่มซึ่งต้องอยู่ในชั้น DAL (ไม่ทราบว่าคลาสบางส่วนต้องอยู่ในแอสเซมบลีเดียวกัน) (3) ตรรกะทางธุรกิจภายในไฟล์ aspx.cs ในเลเยอร์ UI อย่างไรก็ตามดูเหมือนว่ามักจะมีการประนีประนอมเมื่อมันมาถึงสถาปัตยกรรม แต่นี่คือขั้นตอนต่อไป ฉันรู้สึกว่านี่เป็นสิ่งที่ยอมรับได้สำหรับการเปิดตัวครั้งแรกและเมื่อเวลาผ่านไปเราสามารถประเมินแนวทางของเราได้ ขอบคุณสำหรับความช่วยเหลือของคุณทุกคน มันเป็นการดีที่จะได้รับทิศทางเล็กน้อยเพราะบริเวณนี้เป็นส่วนตัว

— คนซ้อน

คำตอบ:

รูปแบบ ASP.NET MVPเป็นสถาปัตยกรรมที่ดีที่สุดสำหรับแอพพลิเคชั่น ASP.NET webforms ในระยะยาว มันกำลังเข้ามาเล่นกับแนวคิด "การแยกความกังวล" ซึ่งเป็นข้อเท็จจริงที่อยู่เบื้องหลังรูปแบบ MV *

คำถามที่ว่าทำไมถึงใช้งาน? - แก้ไขในรายละเอียดในโพสต์นี้ - ASP.NET MVP

— Yusubov
แหล่งที่มา

ปัญหาคือมันจะต้องใช้งานจำนวนมากเพื่อ refactor โครงการเพื่อ MVC ... ถ้าฉันให้มันเป็นแอป WebForms ที่มี Domain Layer (รหัสแรก POCO) Data Access Layer (บริบท db เท่านั้น) และ UI จะ คุณคิดว่านี่เป็นการออกแบบที่ยอมรับได้สำหรับการผลิตหรือไม่? ในภายหลังเราสามารถพิจารณาเปลี่ยนเป็น MVC ฉันคิดว่า

— สแต็คแมน

มันเป็นรูปแบบ MVP (model-view-presenter) และไม่ใช่ MVC (model-view-controller)

— Yusubov

โอ้ขอโทษ - ฉันอ่านผิด ขอบคุณ - ฉันจะอ่านเกี่ยวกับการออกแบบ MVP

— สแต็คแมน

ไม่มีปัญหาฉันหวังว่าคุณจะพบสิ่งที่คุณมองหา :)

— Yusubov

ดูเหมือนว่าการเปลี่ยนเป็น MVP ก็จะเป็นการเปลี่ยนแปลงครั้งใหญ่เช่นกัน ลูกค้าต้องการที่จะเปิดตัวเร็ว ๆ นี้ดังนั้นคุณคิดว่าสถาปัตยกรรมดังกล่าวข้างต้น DAL / DA / UI (แม้ว่าจะไม่เหมาะอย่าง MVP) จะเป็นที่ยอมรับสำหรับแอปพลิเคชันประเภทนี้หรือไม่? หลังจากปล่อยเราสามารถดูการย้ายไป MVP ใน v2

— สแต็คแมน

ใช้รูปแบบ MVP สำหรับการแยกและตรรกะและ UI ดังนั้นในอนาคตคุณสามารถย้ายไปใช้เทคโนโลยี UI ที่แตกต่างกันโดยใช้ตรรกะที่มีอยู่อีกครั้ง
ใช้รูปแบบที่เก็บข้อมูลระหว่าง BL และ DAL เพื่อให้คุณสามารถเปลี่ยนเป็น RDBS ใด ๆ ที่นำตรรกะทางธุรกิจกลับมาใช้ใหม่
นำเลเยอร์แยก (Dll) สำหรับ BO และ DAL ซึ่งเป็นการลดการบำรุงรักษา

— Arunachalam
แหล่งที่มา

ไม่แน่ใจว่าทำไมคนลงคะแนนคำถามนี้ ความซื่อสัตย์นี่เป็นคำตอบที่กระชับที่สุด +1

— Greg Burghardt

ดังที่ ElYusubov กล่าวถึงรูปแบบ MVP นั้นยอดเยี่ยมมาก

แนวคิดหลักคือการกำจัดตรรกะส่วนใหญ่หรือทั้งหมดของคุณออกจากโค้ดเบื้องหลัง ลอจิกไม่ควรถูกผูกไว้กับหน้า ถ้าคุณต้องการใช้ตรรกะจากหน้าหนึ่งไปอีกหน้าหนึ่ง คุณจะถูกล่อลวงให้คัดลอกและวาง หากคุณทำเช่นนี้โครงการของคุณจะสามารถคงสภาพเดิมได้

ดังนั้นสำหรับ starters เริ่ม refactoring ตรรกะของคุณออกจาก behind รหัสและวางไว้ในชั้นธุรกิจ หากคุณจัดการเพื่อกำจัดลอจิกทั้งหมดออกจากโค้ดแล้วคุณสามารถใช้อินเทอร์เฟซที่จำเป็นเพื่อให้เป็น MVP จริง

ตรวจสอบให้แน่ใจว่าการเข้าถึงข้อมูลของคุณแยกจากตรรกะทางธุรกิจของคุณ สร้างชั้นข้อมูลและเริ่ม refactoring ที่ปลายอีกด้วย เนื่องจากคุณใช้ EF4 นี่เป็นปัญหาน้อยเนื่องจาก EF ควรแยกส่วนนี้ออกแล้ว คุณควรจะสามารถย้ายไฟล์ EF ทั้งหมดไปยังโครงการอื่นได้อย่างง่ายดายและเพิ่มการอ้างอิงไปยังโครงการที่ต้องการ ผลประโยชน์ที่เพิ่มขึ้นคุณอาจต้องอ้างอิงตัวแบบข้อมูลของคุณในโครงการอื่น

เพื่อหลีกเลี่ยงการถูกน้ำท่วมให้ทำการเติมน้ำมันทีละน้อย เมื่อใดก็ตามที่คุณสัมผัสชิ้นส่วนของรหัสให้พิจารณาการเปลี่ยนรหัสอีกรอบ หากคุณทำเช่นนี้โครงการของคุณจะสามารถดูแลรักษาได้ตลอดเวลา

แก้ไข

คุณถามว่ามีรหัสอยู่เบื้องหลังสืบทอดคลาสตรรกะทางธุรกิจ ไม่สามารถทำได้เนื่องจากรหัสที่อยู่เบื้องหลังหน้า "is-a" C # ไม่อนุญาตให้มีการสืบทอดหลายรายการดังนั้นคลาส behind รหัสไม่สามารถเป็นได้ทั้งหน้าและวัตถุที่กำหนดเอง คุณต้องแยกความคิดออกเป็นตรรกะ อาจเป็นกรณีที่โค้ดในโค้ดของคุณกำลังทำสิ่งต่าง ๆ มากมาย คลาสควรทำสิ่งหนึ่งและสิ่งหนึ่งเท่านั้น ลองและคิดเกี่ยวกับวิธีที่คุณสามารถดึงแนวคิดการทำงานที่มีอยู่ออกมา ตัวอย่างเช่นสมมติว่าคุณมีหน้าลงทะเบียนและคุณกำลังรวบรวมข้อมูลผู้ใช้ คุณอาจมีปุ่มชื่อ register และเหตุการณ์ click ที่เกี่ยวข้องกับปุ่มนั้น ในกรณีนั้นคุณกำลังบันทึกข้อมูลผู้ใช้และดำเนินการตามที่คุณต้องการ คุณสามารถสร้างการลงทะเบียนวัตถุเพื่อจัดการกับตรรกะนั้นทั้งหมด

สิ่งนี้ไม่เพียง แต่เป็นการแยกที่สะอาดกว่า แต่ยังเป็นวิธีในการบันทึกรหัสของคุณด้วยตนเอง เมื่อมีคนอ่านรหัสของคุณพวกเขาเห็นคุณเรียกวัตถุลงทะเบียนเพื่อให้คุณรู้ว่าเกิดอะไรขึ้น

หากคุณต้องการที่จะปฏิบัติตามรูปแบบ MVP อย่างเคร่งครัดแทนที่จะส่งผ่านพารามิเตอร์ไปยังวัตถุการลงทะเบียนโค้ดที่ล้าหลังจะใช้อินเทอร์เฟซ การใช้อินเทอร์เฟซเป็นหลักจะแมปวัตถุมุมมองทั้งหมด (ฟิลด์ข้อความและอื่น ๆ ) กับอินเตอร์เฟส เช่นสตริงสาธารณะ FirstName {รับ {return txtFirstName.Text; }}

เมื่อเสร็จแล้วคุณสามารถส่งหน้าไปยังวัตถุการลงทะเบียน

Registration.RegisterUser (นี้);

และเมธอด RegisterUser นี้จะใช้อินเตอร์เฟสเป็นพารามิเตอร์

บูลีนสาธารณะ RegisterUser (ผู้ใช้ IUser) {user.FirstName ... }

IUser อินเตอร์เฟสสาธารณะ {สตริงสาธารณะ FirstName; }

หาก MVP นี้ฟังดูสับสนให้มุ่งเน้นไปที่การปรับโครงสร้างใหม่และรู้ว่าประเด็นทั้งหมดนี้คือการใช้งานโค้ดให้เกิดประโยชน์สูงสุด ไม่มีตั้งแต่ในการทำซ้ำตัวเอง นั่นคือหลักแห้ง

— coder
แหล่งที่มา

ขอบคุณสำหรับคำแนะนำที่เป็นประโยชน์ของคุณ ใช่ฉันรู้สึกสับสนเล็กน้อยกับเรื่องนี้ สำหรับฉันดูเหมือนว่า MVC จะเป็นรูปแบบที่ดีที่สุดที่จะใช้ แต่ MVP จะง่ายต่อการบรรลุและเป็นรูปแบบที่ดีที่สุดต่อไป ฉันใช้โค้ดที่อยู่เบื้องหลังไฟล์อยู่เสมอดังนั้นจึงทำให้หัวของฉันมีรอยขีดข่วนเสมอเกี่ยวกับตรรกะทางธุรกิจที่สามารถแยกออกจากงานนำเสนอ ... ดังนั้นฉันควรจะสามารถย้ายไฟล์. aspx.cs ไปยังเลเยอร์โดเมนและมีคำสั่งสืบทอดใน aspx ? การจบลงด้วย 3 เลเยอร์จะทำให้ฉันรู้สึกสบายใจกับการเปิดตัวเวอร์ชั่น 1 - จากนั้นฉันก็สามารถปรับปรุงได้จากตรงนั้น

— ชายกอง

ฉันจะตอบความคิดเห็นของคุณในคำตอบของฉัน รู้สึกอิสระที่จะ upvote คำตอบของฉันถ้าคุณพบว่ามีประโยชน์

— coder