ما مقدار منطق الأعمال الذي يجب أن تحتوي عليه كائنات القيمة؟

Question

يشير أحد المرشدين الذين أحترمهم إلى أن حبة الفول البسيطة هي مضيعة للوقت - وأن الأشياء القيمة "يجب" أن تحتوي على بعض منطق الأعمال حتى تكون مفيدة.

ويقول آخر إنه من الصعب الحفاظ على مثل هذه التعليمات البرمجية، وأن كل منطق الأعمال يجب أن يكون خارجيًا.

أدرك أن هذا السؤال شخصي.السؤال على أي حال - تريد معرفة الإجابات من وجهات نظر أكثر.

Answer 1

من الأفضل أن تتصل بهم نقل الكائنات أو كائنات نقل البيانات (DTO).

في وقت سابق، كان نفس نمط j2ee يسمى "كائن القيمة" لكنهم غيروا الاسم لأنه تم الخلط بينه وبين هذا

http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html

للإجابة على سؤالك، سأضع فقط حدًا أدنى من المنطق في عمليات DTO الخاصة بي، وهو المنطق المطلوب لأسباب العرض.

والأفضل من ذلك، إذا كنا نتحدث عن تطبيق ويب يعتمد على قاعدة البيانات، فسأتجاوز أنماط واستخدامات j2ee الأساسية بيات شتوى أو ال جافا استمرار API لإنشاء نموذج مجال يدعم التحميل البطيء للعلاقات واستخدامه في العرض.

انظر جلسة مفتوحة في العرض.

بهذه الطريقة، لا يتعين عليك برمجة مجموعة من DTOs ويكون لديك كل منطق الأعمال المتاح للاستخدام في طرق العرض/وحدات التحكم الخاصة بك وما إلى ذلك.

Answer 2

إن فكرة تجميع البيانات ومنطق الأعمال معًا هي تعزيز التغليف وكشف أقل قدر ممكن من الحالة الداخلية للكائنات الأخرى.وبهذه الطريقة، يمكن للعملاء الاعتماد على الواجهة بدلاً من التنفيذ.انظر "أخبر ولا تسأل" المبدأ و قانون ديميتر.يجعل التغليف من السهل فهم الحالات التي يمكن أن تكون فيها البيانات، ويسهل قراءة التعليمات البرمجية، ويسهل فصل الفئات، ويسهل بشكل عام اختبار الوحدة.

إن تحديد منطق الأعمال الخارجي (عمومًا في "خدمة" أو فصول "مدير") يقدم أسئلة مثل "أين يتم استخدام هذه البيانات؟" و "ما هي الدول التي يمكن أن تكون فيها؟" أكثر صعوبة في الإجابة.إنها أيضًا طريقة تفكير إجرائية، ملفوفة في شيء ما.هذا يمكن أن يؤدي إلى نموذج المجال فقر الدم.

السلوك الخارجي ليس سيئًا دائمًا.على سبيل المثال، أ طبقة الخدمة قد تنظم كائنات المجال، ولكن دون تولي مسؤولياتها في التلاعب بالدولة.أو، عندما تقوم في الغالب بالقراءة/الكتابة إلى قاعدة بيانات يتم تعيينها بشكل جيد لإدخال النماذج، ربما لا تحتاج إلى نموذج مجال - أو ما يستلزمه ذلك من رسم مؤلم للكائن/التعيين العلائقي - على الإطلاق.

غالبًا ما تعمل كائنات النقل على فصل الطبقات المعمارية عن بعضها البعض (أو عن نظام خارجي) من خلال توفير الحد الأدنى من معلومات الحالة التي تحتاجها الطبقة المستدعية، دون الكشف عن أي منطق عمل.

يمكن أن يكون ذلك مفيدًا، على سبيل المثال عند إعداد المعلومات للعرض:فقط قم بإعطاء العرض المعلومات التي يحتاجها، ولا شيء آخر، حتى يتمكن من التركيز عليها كيف لعرض المعلومات، بدلاً من ماذا المعلومات لعرضها.على سبيل المثال، قد يكون TO عبارة عن تجميع لعدة مصادر للبيانات.

إحدى المزايا هي أن طرق العرض الخاصة بك وكائنات المجال الخاص بك منفصلة.يمكن أن يؤدي استخدام كائنات المجال الخاص بك في JSPs إلى جعل مجالك أكثر صعوبة في إعادة البناء ويعزز الاستخدام العشوائي للحروف والمحددات (وبالتالي كسر التغليف).

ومع ذلك، هناك أيضًا عبء مرتبط بوجود الكثير من كائنات النقل وغالبًا ما يكون هناك الكثير من التكرار أيضًا.تنتهي بعض المشاريع التي شاركت فيها في نهاية المطاف بـ TO التي تعكس بشكل أساسي كائنات المجال الأخرى (والتي أعتبرها نمطًا مضادًا).

Answer 3

هذا يعتمد.

عفوًا، هل أطلقت للتو عبارة مبتذلة؟

السؤال الأساسي الذي يجب طرحه لتصميم كائن هو:هل سيكون المنطق الذي يحكم بيانات الكائن مختلف أو نفس الشيء عند استخدامها/استهلاكها من قبل أشياء أخرى؟

إذا كانت مجالات الاستخدام المختلفة تتطلب منطقًا مختلفًا، فقم بإضفاء الطابع الخارجي عليه.إذا كان هو نفسه بغض النظر عن المكان الذي ينتقل إليه الكائن، ضعه مع الفصل.

Answer 4

تفضيلي الشخصي هو وضع كل منطق الأعمال في نموذج المجال نفسه، أي في كائنات المجال "الحقيقية".لذا، عندما يتم إنشاء كائنات نقل البيانات، فهي في الغالب مجرد تمثيل حالة (غير قابل للتغيير) لكائنات المجال، وبالتالي لا تحتوي على منطق عمل.ومع ذلك، يمكن أن تحتوي على طرق للاستنساخ والمقارنة، ولكن يظل رمز منطق الأعمال موجودًا في كائنات المجال.

Answer 5

ماذا قال كوروس.

كائن القيمة:= كائن صغير وبسيط، مثل المال أو نطاق زمني، لا تعتمد مساواته على الهوية.

DTO:= كائن يحمل البيانات بين العمليات لتقليل عدد استدعاءات الطريقة.

هذه هي التعاريف التي اقترحها مارتن فاولر وأود تعميمها.

Answer 6

وأنا أتفق مع باناجيوتيس:تعد الجلسة المفتوحة في نمط العرض أفضل بكثير من استخدام DTOs.وبعبارة أخرى، فقد وجدت أن التطبيق يكون أبسط بكثير إذا قمت بنقل كائنات المجال الخاص بك (أو بعض المركبات منها) من طبقة العرض الخاصة بك على طول الطريق.

ومع ذلك، من الصعب التنفيذ، لأنك ستحتاج إلى جعل جلسة HttpSession الخاصة بك متزامنة مع وحدة عمل طبقة الثبات الخاصة بك.بعد ذلك سوف تحتاج إلى التأكد من أن جميع تعديلات قاعدة البيانات (أي.الإنشاء والتحديث والحذف) مقصودة.بمعنى آخر، لا تريد أن تكون طبقة العرض تحتوي على كائن مجال، ويتم تعديل الحقل ويستمر التعديل دون أن يقوم رمز التطبيق بحفظ التغيير عمدًا.هناك مشكلة أخرى من المهم التعامل معها وهي التأكد من أن دلالات المعاملات الخاصة بك مرضية.عادةً ما يتم جلب كائن مجال واحد وتعديله في سياق معاملة واحد وليس من الصعب جعل طبقة ORM الخاصة بك تتطلب معاملة جديدة.ماذا يكون التحدي هو معاملة متداخلة، حيث تريد تضمين سياق معاملة ثانٍ داخل السياق الأول المفتوح.

إذا كنت لا تمانع في التحقق من كيفية تعامل واجهة برمجة تطبيقات غير Java مع هذه المشكلات، فمن المفيد النظر إلى السجل النشط لـ Rails، والذي يسمح لصفحات خادم Ruby بالعمل مباشرة مع نموذج المجال واجتياز ارتباطاته.