จะวางตรรกะทางธุรกิจในการออกแบบ MVC ได้ที่ไหน

ฉันสร้างแอปพลิเคชัน MVC Java แบบง่ายที่เพิ่มระเบียนผ่านแบบฟอร์มข้อมูลไปยังฐานข้อมูล

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

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

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

ฉันควรเขียนรหัสสำหรับการคำนวณพื้นหลังนี้ที่ไหน เนื่องจากเป็นกฎและตรรกะทางธุรกิจฉันควรใส่ไว้ในไฟล์ JavaBeans ใหม่หรือไม่

— BriskLabs ปากีสถาน
แหล่งที่มา

เป็นไปได้ที่ซ้ำกันของการพัก OO และทดสอบได้ในขณะที่ทำงานกับฐานข้อมูล

— gnat

คำตอบ:

ตรรกะทางธุรกิจควรจะอยู่ในรูปแบบและเราควรจะมุ่งไขมันรุ่นและผอมควบคุม

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

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

สรุปแนวคิด

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

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

มีความสุขที่ชัดเจนและรัดกุมคำตอบ ..

— hanzolo

@Yusubov คุณช่วยอธิบายความแตกต่างระหว่างตรรกะแอปพลิเคชันและตรรกะทางธุรกิจให้ฉันได้ไหม

— Mohamad

@Moh ในระยะสั้นเหล่านี้เป็นคำที่ฉวัดเฉวียนเพื่อช่วยอธิบายระดับของเทคโนโลยีในแอปพลิเคชัน ตรรกะทางธุรกิจนั้นเป็นกฎของระบบตามข้อกำหนดการทำงาน ตัวอย่างเช่นวัตถุ A ประเภท B ต้องมีสาเหตุมาจาก C และ D แต่ไม่ใช่ E Application Logic นั้นมีข้อกำหนดทางเทคนิคมากกว่าเช่นใช้ Java servlets และ OJB เพื่อคงอยู่กับฐานข้อมูล Oracle

— EL Yusubov

คุณช่วยอธิบายรายละเอียดเกี่ยวกับคำเหล่านี้ได้ไหม :

The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.

[ php-html.net/tutorials/model-view-controller-in-php ]

— revo

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

— EL Yusubov

และเช่นเคยขึ้นอยู่กับความซับซ้อนของโครงการ

ในแอปพลิเคชั่นเล็ก ๆ น้อย ๆ ที่ความซับซ้อนของโมเดลโดเมนมีขนาดค่อนข้างเล็กคุณสามารถใส่ตรรกะในโมเดลและเรียกมันว่าวัน

อย่างไรก็ตามสำหรับแอปพลิเคชั่นที่ไม่สำคัญกับรุ่นที่ซับซ้อนและกฎเกณฑ์ทางธุรกิจมากมาย

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

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

Robert Martin (ลุงบ๊อบ) มีบล็อกโพสต์ที่ดีในเรื่องนี้: The Clean Architecture

— Hakan Deryal
แหล่งที่มา

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

— jgauffin

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

— Hakan Deryal

จากนิยามโดยสตีฟ Burbeck (ทีมสมอลล์ทอล์ค)

The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate

นี้: นั่นคือนิยามของอะแดปเตอร์

— jgauffin

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

— asthasr

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

— DavidS

การวางตรรกะทางธุรกิจไว้ในโมเดลอาจเป็นวิธีที่ดีที่สุด คอนโทรลเลอร์รับสายจากเว็บแอประยะไกล คอนโทรลเลอร์ของบริการเว็บ MVC รับสายและเปลี่ยนเส้นทางการดำเนินการไปยังวิธีการใน BL ตอนนี้ตรรกะทางธุรกิจสามารถที่มีอยู่ใน 'รุ่น' แต่ยังสามารถวางในโฟลเดอร์อื่น ๆ บางพูด, 'ตรรกะทางธุรกิจ' ดังนั้นจึงไม่มีกฎที่ยากและรวดเร็วว่าตรรกะทางธุรกิจจะเป็นอย่างไร

ผมเคยใช้บริการเว็บที่สร้างขึ้นบน MVC 3.0 และภาชนะบรรจุตรรกะทางธุรกิจเป็น MVC MODEL

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

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

— xr280xr