ตรรกะทางธุรกิจใน MVC [ปิด]

ฉันมีคำถาม 2 ข้อ:

ไตรมาสที่ 1 "ตรรกะทางธุรกิจ" ตรงไหนในรูปแบบ MVC ฉันสับสนระหว่าง Model และ Controller

ไตรมาสที่ 2 "ตรรกะทางธุรกิจ" เหมือนกับ "กฎเกณฑ์ทางธุรกิจ" หรือไม่? ถ้าไม่ต่างกันคืออะไร

มันจะดีถ้าคุณสามารถอธิบายด้วยตัวอย่างเล็ก ๆ

กฎทางธุรกิจเป็นไปในรูปแบบ

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

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

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

กำปั้นของทั้งหมด:
ฉันเชื่อว่าคุณกำลังผสมรูปแบบ MVC และหลักการออกแบบที่ใช้ n-tier

การใช้วิธี MVC ไม่ได้หมายความว่าคุณไม่ควรเลเยอร์แอปพลิเคชันของคุณ
มันอาจช่วยถ้าคุณเห็น MVC เหมือนส่วนขยายของเลเยอร์การนำเสนอ

หากคุณใส่รหัสที่ไม่นำเสนอในรูปแบบ MVC คุณอาจท้ายลงในการออกแบบที่ซับซ้อน
ดังนั้นฉันขอแนะนำให้คุณใส่ตรรกะทางธุรกิจของคุณลงในเลเยอร์ธุรกิจแยกต่างหาก

เพียงดูที่นี่: บทความ Wikipedia เกี่ยวกับสถาปัตยกรรมหลายเทียร์

มันพูดว่า:

วันนี้ MVC และ model-view-presenter (MVP) ที่คล้ายกันคือการแยกรูปแบบการออกแบบที่เกี่ยวข้องที่ใช้เฉพาะกับเลเยอร์การนำเสนอของระบบที่ใหญ่ขึ้น

อย่างไรก็ตาม ... เมื่อพูดถึงเว็บแอปพลิเคชันระดับองค์กรการโทรจาก UI ไปยังเลเยอร์ตรรกะทางธุรกิจควรอยู่ในตัวควบคุม (การนำเสนอ)

นั่นเป็นเพราะตัวควบคุมจัดการการโทรไปยังทรัพยากรที่เฉพาะเจาะจงจริง ๆ แล้วสอบถามข้อมูลโดยการโทรไปยังตรรกะทางธุรกิจและเชื่อมโยงข้อมูล (รุ่น) ไปยังมุมมองที่เหมาะสม

คุณหมอบอกว่ากฎเกณฑ์ทางธุรกิจนั้นเข้าสู่โมเดล
นั่นเป็นความจริง แต่เขาผสมผสานโมเดล (การนำเสนอ) ('M' ใน MVC) และโมเดลเลเยอร์ข้อมูลของการออกแบบแอปพลิเคชันแบบเทียร์
ดังนั้นการวางกฎเกณฑ์ทางธุรกิจที่เกี่ยวข้องกับฐานข้อมูลของคุณในรูปแบบ (ชั้นข้อมูล) ของแอปพลิเคชันของคุณ
แต่คุณไม่ควรวางไว้ในรูปแบบของเลเยอร์การนำเสนอที่มีโครงสร้างแบบ MVC เนื่องจากจะใช้กับ UI ที่ระบุเท่านั้น

เทคนิคนี้ไม่ขึ้นอยู่กับว่าคุณใช้การออกแบบโดยใช้โดเมนหรือวิธีการทำธุรกรรมตามสคริปต์

ให้ฉันเห็นภาพนั้นสำหรับคุณ:

เลเยอร์การนำเสนอ: โมเดล - มุมมอง - คอนโทรลเลอร์

ชั้นธุรกิจ: ตรรกะของโดเมน - ตรรกะของแอปพลิเคชัน

ชั้นข้อมูล: ที่เก็บข้อมูล - ชั้นการเข้าถึงข้อมูล

รูปแบบที่คุณเห็นด้านบนหมายความว่าคุณมีแอปพลิเคชันที่ใช้ MVC, DDD และชั้นข้อมูลที่แยกตามฐานข้อมูล
นี่เป็นวิธีการทั่วไปในการออกแบบเว็บแอปพลิเคชันองค์กรขนาดใหญ่

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

นั่นเป็นเคล็ดลับ ... ฉันหวังว่านี่จะช่วย ...

[หมายเหตุ:] คุณควรตระหนักถึงความจริงที่ว่าทุกวันนี้มี "โมเดล" มากกว่าหนึ่งอันในแอปพลิเคชัน โดยทั่วไปแต่ละชั้นของแอปพลิเคชันจะมีรูปแบบของตัวเอง รูปแบบของเลเยอร์การนำเสนอนั้นมีลักษณะเฉพาะ แต่มักจะไม่ขึ้นอยู่กับการควบคุมที่ใช้ เลเยอร์ธุรกิจสามารถมีแบบจำลองที่เรียกว่า "แบบจำลองโดเมน" โดยทั่วไปเป็นกรณีนี้เมื่อคุณตัดสินใจที่จะใช้วิธีการที่ขับเคลื่อนด้วยโดเมน "รูปแบบโดเมน" นี้มีข้อมูลเช่นเดียวกับตรรกะทางธุรกิจ (ตรรกะหลักของโปรแกรมของคุณ) และมักจะเป็นอิสระจากชั้นนำเสนอ เลเยอร์การนำเสนอมักจะเรียกเลเยอร์ธุรกิจบน "เหตุการณ์" (กดปุ่ม ฯลฯ ) เพื่ออ่านข้อมูลจากหรือเขียนข้อมูลไปยังชั้นข้อมูล ชั้นข้อมูลอาจมีรูปแบบของตัวเองซึ่งโดยทั่วไปจะเกี่ยวข้องกับฐานข้อมูล

คำถามคือ: สิ่งนี้เหมาะสมกับแนวคิด MVC อย่างไร

คำตอบ -> ไม่!
แต่มันไม่สมบูรณ์
นี่เป็นเพราะ MVC เป็นวิธีการที่พัฒนาขึ้นในปลายปี 1970 สำหรับภาษาการเขียนโปรแกรม Smalltalk-80 ในช่วงเวลานั้น GUIs และคอมพิวเตอร์ส่วนบุคคลค่อนข้างแปลกและอินเทอร์เน็ตทั่วโลกไม่ได้ถูกคิดค้นขึ้นมา! ภาษาโปรแกรมและ IDEs ส่วนใหญ่ในปัจจุบันได้รับการพัฒนาในปี 1990 ในเวลานั้นคอมพิวเตอร์และส่วนต่อประสานกับผู้ใช้นั้นแตกต่างจากในทศวรรษ 1970 อย่างสิ้นเชิง
คุณควรระลึกไว้เสมอเมื่อพูดถึง MVC
Martin Fowler ได้เขียนบทความที่ดีมากเกี่ยวกับ MVC, MVP และ GUI ของวันนี้

ตรรกะทางธุรกิจในความคิดของฉันไม่ใช่คำจำกัดความที่แม่นยำ อีแวนส์พูดในหนังสือของเขาเรื่อง Domain Driven Design เกี่ยวกับตรรกะทางธุรกิจสองประเภท:

• ตรรกะโดเมน
• แอปพลิเคชันตรรกะ

การแยกนี้มีความชัดเจนมากขึ้น และด้วยความตระหนักว่ามีกฎเกณฑ์ทางธุรกิจที่แตกต่างกันก็ทำให้เกิดการตระหนักว่าพวกเขาไม่จำเป็นต้องไปที่เดียวกันทั้งหมด

ตรรกะโดเมนคือตรรกะที่สอดคล้องกับโดเมนจริง ดังนั้นหากคุณกำลังสร้างแอปพลิเคชันการบัญชีกฎของโดเมนจะเป็นกฎเกี่ยวกับบัญชีการโพสต์การเก็บภาษี ฯลฯ ในเครื่องมือการวางแผนซอฟต์แวร์แบบว่องไวกฎจะเป็นสิ่งต่าง ๆ เช่นการคำนวณวันที่เผยแพร่ตามความเร็วและเรื่องราวใน Backlog เป็นต้น

สำหรับแอปพลิเคชันทั้งสองประเภทนี้การนำเข้า / ส่งออก CSV อาจมีความเกี่ยวข้อง แต่กฎของการนำเข้า / ส่งออก CSV นั้นไม่เกี่ยวข้องกับโดเมนจริง ตรรกะชนิดนี้เป็นตรรกะแอปพลิเคชัน

ตรรกะของโดเมนจะเข้าสู่เลเยอร์โมเดลอย่างแน่นอน โมเดลจะสอดคล้องกับเลเยอร์โดเมนใน DDD

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

A1 : ตรรกะทางธุรกิจไปมีส่วนร่วมในModel MVCบทบาทของModelคือการมีข้อมูลและตรรกะทางธุรกิจ Controllerในทางกลับกันมีหน้าที่รับข้อมูลผู้ใช้และตัดสินใจว่าจะทำอย่างไร

A2 : การเป็นส่วนหนึ่งของBusiness Rule Business Logicพวกเขามีhas aความสัมพันธ์ มีBusiness LogicBusiness Rules

Wikipedia entry for MVCลองดูที่ ไปที่ภาพรวมที่กล่าวถึงการไหลของMVCรูปแบบ

Wikipedia entry for Business Logicนอกจากนี้ยังมองไปที่ มันบอกว่าBusiness Logicจะประกอบด้วยและBusiness RulesWorkflow

เป็นคำตอบสองสามข้อที่ชี้ให้เห็นฉันเชื่อว่ามีความเข้าใจผิดบางอย่างเกี่ยวกับสถาปัตยกรรมแบบหลายระดับกับ MVC

สถาปัตยกรรมแบบหลายชั้นเกี่ยวข้องกับการแบ่งแอปพลิเคชันของคุณเป็นเทียร์ / เลเยอร์ (เช่นการนำเสนอตรรกะทางธุรกิจการเข้าถึงข้อมูล)

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

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

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

นี่เป็นคำถามที่ตอบแล้ว แต่ฉันจะให้ "หนึ่งเซ็นต์" ของฉัน:

กฎทางธุรกิจอยู่ในรูปแบบ "รุ่น" ประกอบด้วยเสมอ (แยกทางตรรกะหรือทางกายภาพ):

• รูปแบบการนำเสนอ - ชุดของคลาสที่เหมาะสำหรับใช้ในมุมมอง (ซึ่งปรับให้เข้ากับ UI / การนำเสนอเฉพาะ)
• โมเดลโดเมน - ส่วนที่ไม่ขึ้นกับ UI ของโมเดลและ
• พื้นที่เก็บข้อมูล - ส่วนที่รับรู้การจัดเก็บข้อมูลของ "รุ่น"

กฎเกณฑ์ทางธุรกิจอยู่ในรูปแบบโดเมนถูกเปิดเผยในรูปแบบการนำเสนอที่เหมาะสมกับรูปแบบ "งานนำเสนอ" และบางครั้งอาจมีการทำซ้ำ (หรือบังคับใช้) ใน "ชั้นข้อมูล"

มันไม่สมเหตุสมผลเลยที่จะทำให้เลเยอร์ธุรกิจของคุณอยู่ใน Model สำหรับโครงการ MVC

สมมติว่าเจ้านายของคุณตัดสินใจที่จะเปลี่ยนเลเยอร์การนำเสนอเป็นอย่างอื่นคุณจะเมา! เลเยอร์ธุรกิจควรเป็นชุดประกอบแยกต่างหาก แบบจำลองประกอบด้วยข้อมูลที่มาจากชั้นธุรกิจที่ผ่านไปยังมุมมองที่จะแสดง จากนั้นในการโพสต์ตัวอย่างรุ่นผูกกับคลาสบุคคลที่อยู่ในชั้นธุรกิจและเรียก PersonBusiness.SavePerson (p); โดยที่ p คือคลาส Person นี่คือสิ่งที่ฉันทำ (ชั้น BusinessError หายไป แต่จะไปใน BusinessLayer ด้วย):

Q1:

ตรรกะธุรกิจสามารถพิจารณาได้สองประเภท:

1. Logics โดเมนเช่นการควบคุมที่อยู่อีเมล (ไม่ซ้ำกัน, ข้อ จำกัด , ฯลฯ ), รับราคาของผลิตภัณฑ์สำหรับใบแจ้งหนี้หรือการคำนวณราคารวมของ shoppingCart ตามวัตถุผลิตภัณฑ์

2. กระบวนการทำงานที่กว้างขวางและซับซ้อนมากขึ้นซึ่งเรียกว่ากระบวนการทางธุรกิจเช่นการควบคุมกระบวนการลงทะเบียนสำหรับนักเรียน (ซึ่งมักจะมีหลายขั้นตอนและต้องการการตรวจสอบที่แตกต่างกัน

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

ดูคำตอบนี้สำหรับความแตกต่างเฉพาะระหว่างรุ่นและคอนโทรลเลอร์ลิงก์นี้สำหรับคำจำกัดความที่แน่นอนมากและลิงค์นี้สำหรับตัวอย่าง Android ที่ดี

ประเด็นก็คือบันทึกที่กล่าวถึงโดย "โคลน" และ "แฟรงก์" ด้านบนอาจเป็นจริงเช่นเดียวกับ "พีท" (ตรรกะทางธุรกิจสามารถวางในรูปแบบหรือตัวควบคุมตามประเภทของตรรกะทางธุรกิจ)

สุดท้ายโปรดทราบว่า MVC แตกต่างจากบริบทไปยังบริบท ตัวอย่างเช่นในแอปพลิเคชัน Android คำจำกัดความทางเลือกบางข้อแนะนำว่าแตกต่างจากที่ใช้บนเว็บ (ดูตัวอย่างการโพสต์นี้)

Q2:

ตรรกะทางธุรกิจทั่วไปมากขึ้นและ (ตามที่ "decyclone" ดังกล่าวข้างต้น) เรามีความสัมพันธ์ดังต่อไปนี้:

กฎเกณฑ์ทางธุรกิจ log ตรรกะทางธุรกิจ

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

Model = code สำหรับการดำเนินการฐานข้อมูล CRUD

Controller = ตอบสนองต่อการกระทำของผู้ใช้และส่งคำขอของผู้ใช้สำหรับการดึงข้อมูลหรือลบ / อัปเดตไปยังโมเดลภายใต้กฎเกณฑ์ทางธุรกิจเฉพาะสำหรับองค์กร กฎทางธุรกิจเหล่านี้สามารถนำมาใช้ในคลาสผู้ช่วยหรือถ้าพวกเขาไม่ซับซ้อนเกินไปเพียงแค่ในการดำเนินการควบคุม ในที่สุดคอนโทรลเลอร์ขอให้มุมมองอัปเดตตัวเองเพื่อให้ข้อเสนอแนะกับผู้ใช้ในรูปแบบของจอแสดงผลใหม่หรือข้อความเช่น 'อัพเดตขอบคุณ' ฯลฯ

View = UI ที่สร้างขึ้นตามแบบสอบถามในโมเดล

ไม่มีกฎที่ยากและรวดเร็วเกี่ยวกับที่ที่กฎธุรกิจควรจะไป ในการออกแบบบางอย่างพวกเขาเข้าไปในรูปแบบในขณะที่คนอื่น ๆ พวกเขาจะรวมอยู่ในการควบคุม แต่ฉันคิดว่ามันดีกว่าที่จะเก็บมันไว้กับคอนโทรลเลอร์ ปล่อยให้รุ่นกังวลเกี่ยวกับการเชื่อมต่อฐานข้อมูลเท่านั้น