كيف تصمم في Java EE؟

Question

دعنا نقول ، لقد قررت الذهاب مع Java EE Stack لتطبيق مؤسستي.

الآن ، لنمذجة المجال (أو: لتصميم M من MVC) ، أي واجهات برمجة التطبيقات التي يمكنني تحملها بأمان واستخدامها ، والتي يجب أن أبتعد عن ... على سبيل المثال ، عبر طبقة من التجريد؟

فمثلا،

1. هل يجب أن أمضي قدمًا وأتخلف عن طرازتي مع مكالمات إلى API لـ Hibernate/JPA؟ أو ، هل يجب أن أقوم ببناء تجريد ... طبقة ثبات خاصة بي لتجنب الترميز الشاق ضد هاتين واجهات برمجة تطبيقات الثبات المحددة؟ لماذا أسأل هذا: قبل بضع سنوات ، كان هناك API Kodo الذي تحل محله السبات. إذا كان أحدهم قد صمم طبقة ثباتًا وربط بقية النموذج ضد هذه الطبقة (بدلاً من القمامة النموذج مع مكالمات إلى API بائع محدد) ، فقد سمح لأحد (نسبيًا) بالتبديل من Kodo إلى السبات إلى XYZ.

2. هل يوصى باستخدام عدواني لـ *QL المقدم من بائع الثبات في نموذج المجال الخاص بك؟ لست على دراية بأي مشكلات في العالم الحقيقي (مثل الأداء ، قابلية التوسع ، قابلية النقل ، إلخ) الناشئة عن الاستخدام الكثيف للغة الشبيهة بـ HQL. لماذا أسأل هذا: أود أن أتجنب ، قدر الإمكان ، كتابة رمز مخصص عندما يمكن تحقيق الشيء نفسه من خلال لغة الاستعلام التي تكون أكثر قابلية للحمل من SQL.

آسف ، لكنني مبتدئ كامل في هذا المجال. أين يمكنني العثور على مزيد من المعلومات حول هذا الموضوع؟

Answer 1

هذا ما أعتقد أنه الرأي التقليدي:

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

يجب ألا يتصل الكيان بطبقة الوصول إلى البيانات مباشرة. لكن طبقة العمل سوف ، بطريقة لتحميل واستمرار كيانات نموذج المجال.

إذا قمت بتخطيط ذلك إلى تقنيات Java ee ، فعادة ما تحصل على شيء مثل:

• الكيانات -> Pojo مع التعليقات التوضيحية/JPA. لاحظ أن التعليقات التوضيحية لا تعني اقترانًا ضيقًا مع JPA/Hibernate ، يمكن استخدام نفس PoJO في مكان آخر دون سبات.
• طبقة العمل -> جلسة EJB أو الربيع
• طبقة الوصول إلى البيانات -> JPA/Hibernate

هذا رسم تقريبي وهناك الكثير من المتغيرات الممكنة. يمكنك تخطي جلسة EJB وتنفيذ طبقة العمل بطريقة أخرى. يمكنك أيضًا أن تقرر أن تتصل طبقة العمل بجلسة JPA/Hibernate/EntityManager مباشرة ، وفي هذه الحالة يكون JPA/Hibernate هو DAL حقًا ، أو قد ترغب في الوصول ).

فيما يتعلق بـ HQL ، حاول التمسك بما هو محمول ، وإذا كنت تستخدم SQL الأصلي ، اتبع اتفاقيات SQL-92. إذا أصبحت المواد معقدة ، فربما تقدم DAOS. وبهذه الطريقة ، أنت تعلم أن المكان الوحيد الذي يوجد فيه استعلامات HQL في DAOS. يمكنك أيضًا أولاً تنفيذ منطق الاستعلام "من الناحية الإجرائية" في DAO ، وإذا كان لديك مشكلة في الأداء ، فعليك إعادة تنفيذها مع استعلام HQL أكثر تعقيدًا.

تعديل

بخصوص أسئلتك في التعليق:

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

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

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

تحرير 2

حسنًا ، هناك جمل أخرى حول المعاملات:

يجب أن تدار المعاملات من الناحية المفاهيمية في طبقة العمل ؛ يعتمد تعريف ما يجب القيام به في وحدة عمل واحدة لتكون متسقة في الواقع على منطق التطبيق.

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

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

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

Answer 2

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

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