الفصل بين العرض التقديمي ومستويات الأعمال مع الربيع

Question

في مشروعي الذي اكتمل للتو، كنت أعمل على تشغيل المعاملات الموزعة.

لقد قمنا بتنفيذ ذلك باستخدام Arjuna Transaction Manager الخاص بـ JBoss وحدود المعاملات التصريحية الخاصة بـ Spring.

بدا تسلسل طلبنا كما يلي:

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

ما يعنيه هذا هو أن لدينا حربًا لخدمة servlet الآمن الخاص بنا وEAR لخدمة SLSB الخاص بنا.

يحتوي SLSB الخاص بنا على كتلة تهيئة ثابتة لتشغيل سياق تطبيق Spring الخاص بنا.

لا أحب مزيج التقنيات، لكني أحب الفصل بين مستويات العرض التقديمي والأعمال، والتي يمكن أن توجد في مواقع فعلية مختلفة.

سأكون مهتمًا بمعرفة ما يقترحه الآخرون لفصل المستويات عند استخدام Spring؟

Answer 1

إن طلب خادم تطبيق EJB3 فقط لـ SLSB الذي يمثل واجهة لا يبدو أنه يستحق الجهد المبذول بالنسبة لي.لا يوجد سبب يمنعك من إزالة ذلك وتشغيل servlet الخاص بك مباشرة مع Spring.يمكنك إضافة contextLoaderListener إلى WAR لتحميل ApplicationContext ثم WebApplicationContextUtils للحصول عليه.وبدلاً من ذلك، يمكنك استخدام SpringMVC أو Struts أو تقنيات الويب الأخرى إذا كنت بحاجة إلى القيام بأكثر مما يسمح به Servlet بمفرده.

Answer 2

يتمثل النهج النموذجي إلى حد كبير في تحديد طبقة الويب وطبقة الخدمة وطبقة DAO وإرفاق دلالات المعاملات بطبقة الخدمة.قد تكون طبقة الخدمة عبارة عن مجموعة من POJOs مع التعليقات التوضيحية @Transactional، على سبيل المثال.قد تكون طبقة الويب عبارة عن وحدات تحكم Spring Web MVC.في هذا الأسلوب، تقوم طبقة الويب بشكل أساسي بتكييف طبقة الخدمة مع HTTP.فصل جيد ولا حاجة لـ SLSBs هنا.

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