سؤال

بينما كنت أتعلم JSF2، أدركت أنني لست متأكدًا من مكونات الدعم التي يجب أن تكون عليها.من وجهة نظر التصميم، ما هو الفرق بين EJBs و @ManagedBeans?

في النهاية، سأستخدم JPA، لذا يعد EJB خيارًا طبيعيًا لطبقة الأعمال.هل من الممارسات الجيدة استخدام EJB مباشرة من JSF (كما هو موضح هنا)?

في الوقت الحالي أنا أميل إلى الاستخدام @ManagedBeans للمكونات التي لا تحتاج إلى الوصول إلى طبقة الأعمال (على سبيل المثال.عرض المساعدين) أو التعامل مع بيانات الطلب/الجلسة.لأغراض أخرى، على سبيل المثال.بإدراج شيء ما في الشبكة، سأتمكن من الوصول مباشرة إلى EJB.

هل هذا تصميم جيد؟هل يجب أن أستخدم @ManagedBeans لجميع حبوب الدعم من أجل فصل الطبقة النظيفة، حتى لو كانت في بعض الحالات يتم تفويضها فقط إلى EJB؟

هل كانت مفيدة؟

المحلول

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

في مثالي استخدام ميزات JSF مع converters, rendered, validator, ، إلخ.حبة الدعم استطاع في الواقع يكون رمز منطق الأعمال نظيفًا.لكن من الناحية العملية، يتسرب بعض المنطق المتعلق بالعرض التقديمي بشكل متكرر.

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

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

بالنسبة لي، إنها في النهاية مسألة ذوق وحجم المشروع.أستطيع أن أتخيل أنه بالنسبة لمشروع صغير/متوسط، فإن استخدام EJB في JSF يعمل بشكل جيد.بالنسبة للمشروع الأكبر حيث تكون هذه الصرامة أمرًا بالغ الأهمية، تأكد من عدم ربط الطبقات.

نصائح أخرى

في Java EE 6 هناك بعض التداخل بين مختلف الفاصوليا المدارة: الفاصوليا المدارة JSF (@ managedbean)، الفاصوليا المدارة CDI (ادارة) و الفاصوليا EJB (ESTATSYLED، STATEFULL، Singleton).

في طبقة الرأي، لا أرى أي ميزة خاصة للالتصاق مع managedbean. يبدو أن Niniant Suriant CDI يبدو أنه قادر على فعل نفس الشيء والمزيد، على سبيل المثال، توفر لك الوصول إلى نطاق التحويل.

يبدو أن التفكير الحالي هو أنه سيتم تجديد نموذج مكون EJB في نهاية المطاف كمجموعة من التعليقات التوضيحية CDI. وخاصة عضو مجموعة الخبراء رضا رحمان يتردد في كثير من الأحيان في هذا. انظر على سبيل المثال حقن التبعية في Java EE 6 - الجزء 1

في الوقت الحالي، لم يحدث هذا، لذلك تظل حبوب EJB أسهل مكان لوضع منطق الأعمال، خاصة عندما يتم استخدام JPA للاستمرار.

ومع ذلك، سواء ك CDI ستحصل على قدرات EJB، فإن IMHO لا تزال أفضل الممارسات لاستخدام فاصوليا منفصلا لمفهوم "Backing Bean" وفول منفصل عن "منطق الأعمال".

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

يجب أن لا تعرف الخدمات (منطق الأعمال) أي شيء عن أي عرض تقديمي معين. يجب أن تكون قابلة للاستخدام بشكل جيد على قدم المساواة من فاصوليات دعم JSF، JAX-RS، Servlets، جافا SE المستقل للعملاء عن بعد أو أيا كان.

حتى لو أصبحت جميع الفول حبوب CDI، فهذا لا يغير هذا التقسيم الأساسي للمسؤولية.

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

كما هو واحد لاستخدامه لما، أود فقط التمسك @ManagedBean للإشارة إلى نموذج JSF - ما يرتبط بآراء JSF المحددة أو أكثر. يمكنك استخدام تماما @EJBS إلى منطق الأعمال غير المحددة غير JSF و / أو Datamodels. يمكنك بحقن @EJBفي نموذج JSF وتفويضه في أساليب العمل وربما أيضا Getters / Setters، ولكن يجب ألا تفعل ذلك في الاتجاه الآخر، أي لا يحدد نموذج JSF في @EJB, ، هذا يؤدي إلى اقتران ضيق وسيجعل @EJBق غير قابلة للاستخدام خارج سياق JSF. بقدر ما يبدو التصميم الخاص بك جيدا، طالما كنت تشاهد عدم استيراد أي شيء من javax.faces حزمة في @EJB صف دراسي.

عن طريق استدعاء EJB من XHTML الخاص بك، فأنت تقدم اقتران ضيق بين اختيار التنفيذ في الرأي والطبقة التجارية.

إذا كنت تستخدم الفاصوليا المدارة لدعوة EJB، [أو حتى، وضعت في مندوب أعمال]، ستتمكن من تغيير مستوى عملك تماما إلى الربيع دون التأثير على طبقة العرض (XHTML).

هو ممكن من الناحية الفنية، وسهل جدا بالنسبة لك (JSR 299) أن تكون قادرا على استخدام EJB كاصوليك المدارة، وهذا ربما ما يريده هؤلاء البائعون القيام به - لا يتم لصقها على التفاصيل. ولكن ما إذا كان هذا هو الشيء الصحيح الذي يجب القيام به؟ - رقم.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top