ฉันยังใหม่กับ MVC แต่จากสิ่งที่ฉันได้เรียนรู้จนถึงตอนนี้ (เช่น ที่นี่ โดย ScottGu) เราควรมีความปรารถนาที่จะ "ควบคุมผอม" มากกว่า "อ้วน"
แถมความจริงที่ว่ามุมมองนั้นบางโดยเนื้อแท้ และคุณจะได้รับโค้ด จำนวนมาก ในโมเดลของคุณ
ดังนั้นคำถามของฉันคือ - คุณจะแบ่งพาร์ติชันโค้ดในโมเดลของคุณไปยังส่วนลอจิคัลต่าง ๆ เพื่อลดความซับซ้อนได้อย่างไร
คุณใช้ Data Access Layer และ Business Logic Layer ภายในตัวโมเดลเองหรือไม่ (ซึ่งฉันเดาว่าน่าจะยังคงมีอยู่มาก ของโค้ด) หรือมีวิธีที่ดีกว่าในการทำเช่นนั้น?
ขอบคุณ
เลเยอร์ที่เราใช้คือ:
มุมมอง - บางที่สุด - ไม่มีเหตุผล - แค่แสดง
ดูโมเดล - พิมพ์อย่างยิ่งต่อมุมมอง - ไม่มีเอนทิตี แต่มีเพียงฟิลด์ที่เราต้องการในมุมมองเดียว
ตัวควบคุม - เพียงกำหนดเส้นทางและโทรไปยัง VMS จัดการข้อยกเว้นที่เกิดขึ้นจากระดับที่ต่ำกว่าโดยการกำหนดเส้นทางไปยังหน้าแสดงข้อผิดพลาด
ดูบริการโมเดล - สร้างและคลายโมเดลมุมมองลงในเอนทิตี EF ไม่มีตรรกะในการเข้าถึงข้อมูล หนึ่ง VMS ต่อตัวควบคุม ใช้ AutoMapper อย่างหนักเพื่อถ่ายโอนข้อมูลของโมเดลมุมมองไปยังเอนทิตี
บริการธุรกิจ - จุดหลักของการเข้าถึงข้อมูล หนึ่ง BS ต่อตัวควบคุม ใช้ที่เก็บข้อมูลมากเท่าที่จำเป็นในการทำงาน ตัวควบคุมขอบเขตธุรกรรมที่นี่ VMS ทำการเรียก BS เพียงครั้งเดียว ซึ่งจะรวมการเรียก DB ที่จำเป็นทั้งหมดไว้ในธุรกรรมเดียว หากจำเป็น เราคาดว่า BS จะเรียกใช้บริการภายนอกในอนาคต
ที่เก็บ - หนึ่งรายการต่อ (ระดับบนสุด) เอนทิตี - ดำเนินการ CRUD ทั้งหมดสำหรับกลุ่มเอนทิตี เอนทิตีของเราเป็นกราฟวัตถุขนาดใหญ่และซับซ้อน ดังนั้นเราจึงจัดการพาเรนต์บนสุดต่อพื้นที่เก็บข้อมูล
บริบท - แผ่นบางๆ รอบๆ EF สร้างบริบทเพื่อให้ฉันสามารถเยาะเย้ยได้
ในแง่ของ MVC - ส่วน Model ประกอบด้วยทุกสิ่งที่อยู่ด้านล่างคอนโทรลเลอร์
ต่อไปนี้คือวิธีที่ฉันมักจะแบ่งสิ่งต่าง ๆ และแนะนำให้แบ่งสิ่งต่าง ๆ :
รุ่น: แสดงถึงข้อมูล ไม่ควรมีโค้ดที่เกี่ยวข้องกับการแสดงผล ไม่ควรมีรหัสสำหรับการเผยแพร่/สมัครรับข้อมูลอัปเดต ไม่ควรมีโค้ดอ่าน/เขียน
โมเดล I/O: โค้ดที่อ่าน/เขียนโมเดลไปยัง/จากดิสก์ เครือข่าย SQL หรือที่จัดเก็บสำรองอื่นๆ โดยทั่วไปควรแยกจากอ็อบเจ็กต์โมเดลเอง เพื่อให้มีพื้นที่จัดเก็บข้อมูลสำรอง
โครงสร้างพื้นฐานของตัวควบคุม: ให้ wrapper ที่ด้านบนของโมเดลที่เพิ่มพฤติกรรมการเผยแพร่ / สมัครสมาชิกให้กับโมเดล (เช่น สัญญาณเหตุการณ์การแจ้งเตือนการเปลี่ยนแปลงเมื่อโมเดลเปลี่ยนแปลง)
ตัวควบคุม: สร้างโมเดลและมุมมอง โหลดโมเดลจากที่เก็บข้อมูล ลงทะเบียนตัวจัดการบนโมเดลเพื่ออัปเดตมุมมองเมื่อมีการเปลี่ยนแปลง ลงทะเบียนตัวจัดการบนมุมมองเพื่ออัปเดตโมเดลในการดำเนินการดู และเพื่อบันทึก / จัดเก็บโมเดลเมื่อมีการเรียกใช้การดำเนินการบันทึก
ดู: ส่วนประกอบตั้งแต่หนึ่งรายการขึ้นไปที่เรนเดอร์โมเดล
วิธีหนึ่งที่ฉันพบว่าใช้งานได้ดีจริงๆ คือการแยกโมเดลอย่างที่คุณพูด ออกเป็น Data Service Layer และ Business Logic Layer รากฐานของเลเยอร์ Business Logic คือออบเจ็กต์ที่มีการแมปกับตารางฐานข้อมูลเกือบทั้งหมด Data Service Layer จะสามารถแมปออบเจ็กต์เหล่านี้ลงในฐานข้อมูลได้โดยตรงเมื่อมีการเปลี่ยนแปลงหรือเมื่อมีการสร้างสิ่งใหม่
เมื่อฉันต้องจัดการกับวัตถุที่ปฏิเสธที่จะแมปอย่างเรียบร้อยกับตารางเดียวในฐานข้อมูล ฉันจะสร้างส่วนหน้าหรือวัตถุผสมซึ่งตรรกะทางธุรกิจสามารถโต้ตอบได้ สิ่งนี้ทำให้แน่ใจได้ว่าแม้ว่า Business Logic จะถือว่าเป็นหนึ่งเดียวกัน แต่ Data Service Layer ยังคงเห็นว่ามีความแตกต่างกันและสามารถอัปเดตได้เฉพาะที่จำเป็นเท่านั้น
ฉันขอแนะนำบทความนี้เกี่ยวกับ การจับคู่ Objects กับ Relational Model เพื่อช่วยคุณในการเริ่มต้น
คุณอาจต้องการดู Service Layer ที่สามารถช่วยในการพยายามทำให้คอนโทรลเลอร์บางที่สุดได้ คอนโทรลเลอร์สามารถมอบหมายการดำเนินการบางอย่างให้กับชั้นบริการเพื่อดำเนินการได้ โดยปกติแล้ว เลเยอร์นี้จะขึ้นอยู่กับ Data Access Layer (DAO) สำหรับการคงอยู่ของออบเจ็กต์โดเมนของคุณ ในกรณีนี้ คอนโทรลเลอร์ของคุณนั้นเรียบง่ายเพื่อประสานงานโฟลว์การควบคุมของคุณ แนวคิดหลักของ MVC คือการแยกข้อกังวล ใน MVC แบบดั้งเดิม ตรรกะการนำเสนอจะแชร์ระหว่างคอนโทรลเลอร์และมุมมองของคุณ ในกรณีของ MVP (รูปแบบอื่นของ MVC) ตรรกะการนำเสนอทั้งหมดจะจัดการโดยคอนโทรลเลอร์
