ما هي مبادئ تطوير تطبيقات الويب مع أطر Java القائمة على الإجراء؟

Question

خلفية

سأقوم بتطوير تطبيق ويب جديد مع Java. إنه ليس كبيرًا جدًا أو معقدًا للغاية ولدي وقت كافٍ حتى يبدأ "رسميًا".

لدي بعض خلفية تطوير JSF/Facelets (حوالي نصف عام). ولدي أيضًا بعض انتهاء الصلاحية مع JSP+JSTL.

في الغرض من التعليم الذاتي (وأيضًا من أجل العثور على أفضل الحلول) ، أود أن أنتج النموذج الأولي للمشروع الجديد مع أحد الأطر القائمة على الإجراء. في الواقع ، سأختار بين Spring MVC و Stripes.

مشكلة

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

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

1. تقديم المحتوى: يمكنني تطبيق مكون جاهز للاستخدام من مكتبات JSF القياسية (Core و HTML) أو من Libs الطرف الثالث (مثل Richfaces). يمكنني الجمع بين المكونات البسيطة ويمكنني بسهولة إنشاء مكوناتي الخاصة التي تستند إلى مكونات قياسية.
2. تقديم البيانات (البدائية أو الأنواع المرجعية) بالتنسيق الصحيح: يسمح كل مكون بتحديد أ محول لتحويل البيانات في كلا الاتجاهين (لتقديم وإرسال إلى الخادم). المحول هو ، كالعادة ، فئة بسيطة مع طريقتين صغيرتين.
3. التنقل في الموقع: أنا حدد مجموعة من حالات الملاحة في الوجوه config.xml. ثم أقوم بتحديد جوز الإجراء للرابط (أو الزر) الذي يجب أن يتطابق مع واحد أو أكثر من حالات التنقل. يتم اختيار أفضل مباراة بواسطة JSF.
4. تنفيذ التدفق (المعالجات المتعددة على سبيل المثال): أنا أستخدم JSF 1.2 لذلك أنا أستخدم أوركسترا أباتشي لنطاق التدفق (المحادثة).
5. معالجة النموذج: لديّ Java-bean قياسيًا جدًا (يدعم الفاصوليا بشروط JSF) مع بعض النطاق. أنا "خريطة" الحقول النموذج على خصائص الفول هذه. إذا سارت الأمور على ما يرام (لا يوجد استثناءات وتم تمرير التحقق) ، فسيتم تعيين كل هذه الخصائص مع قيم من حقول النموذج. ثم يمكنني استدعاء طريقة واحدة (محددة في الزر عمل السمة) لتنفيذ بعض المنطق وإرجاع سلسلة التي ينبغي أن واحدة من حالات التنقل الخاصة بي للانتقال إلى الشاشة التالية.
6. نماذج التحقق من الصحة: يمكنني إنشاء مصلحة مخصصة (أو الاختيار من بينها) وإضافته إلى كل مكون تقريبًا. تحتوي المكتبات الثالثة على مجموعات من الأجسام المخصصة لـ Ajax. يعمل المدققون القياسيون فقط بعد إرسال الصفحة. في الواقع ، لا أحب كيفية عمل التحقق من الصحة في JSF. الكثير من السحر هناك. العديد من المكونات القياسية (أو ربما جميعها) لديها التحقق من صحة محددة مسبقًا ومن المستحيل تعطيلها (ربما ليس دائمًا ، لكنني واجهت العديد من المشكلات معها).
7. دعم أياكس: العديد من المكتبات ذات الطرف الثالث (MyFaces ، Icefaces ، OpenFaces ، OtherPrefixFaces ...) لديها دعم قوي Ajax ويعمل بشكل جيد. حتى تلتقي مشكلة. الكثير من السحر هناك كذلك. من الصعب للغاية أن نجعلها تعمل إذا لم تنجح لكنك فعلت بشكل صحيح كما هو موضح في الدليل.
8. عناوين URL سهلة الاستخدام: يقول الناس أن هناك بعض المكتبات لذلك. ويمكن القيام به مع المرشحات كذلك. لكنني لم أحاول قط. يبدو معقدًا جدًا للمظهر الأول.

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

Answer 1

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

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

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

---

تقديم المحتوى: يمكنني تطبيق مكون جاهز للاستخدام من مكتبات JSF القياسية (Core و HTML) أو من libs الطرف الثالث (مثل Richfaces). يمكنني الجمع بين المكونات البسيطة ويمكنني بسهولة إنشاء مكوناتي الخاصة التي تستند إلى مكونات قياسية.

هذا مشابه. Core ، HTML ، FMT ، إلخ. وكذلك أي علامات مخصصة تجدها ، Inc. العرض: علامة ، علامة الحزمة ، وإنشاء خاص بك. ومع ذلك ، من الواضح أنك لا تتعامل على مستوى المكون الآن ، فأنت تتعامل مع علامة تحدد ما هو موجود على الصفحة / إرسالها إلى أو من الخادم.

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

يحتوي Stripes على العديد من المحولات المدمجة ، ومن السهل إنشاء محولات مخصصة لأنواع البيانات الأكثر تعقيدًا. يدعم Stripes هياكل بيانات معقدة للغاية ليتم تعيينها مع القليل من المتاعب. مدموج مع Stripersist, ، على سبيل المثال ، يمكنني وضع كائن النموذج الخاص بي مباشرة على ActionBean ، ووضع بعض الحقول على النموذج ، وسيقوم Stripersist بترطيب النموذج من DB (استنادًا إلى PK) وتحديث ذلك مع الحقول التي أضعها على الشكل - كل ذلك قبل إطلاق السيطرة لي على Actionbean.

التنقل في الموقع: حدد مجموعة من حالات التنقل في الوجوه- config.xml. ثم أقوم بتحديد جوز الإجراء للرابط (أو الزر) الذي يجب أن يتطابق مع واحد أو أكثر من حالات التنقل. يتم اختيار أفضل مباراة بواسطة JSF.

يعتمد التنقل في Stripes على ما تسميه ActionBeans ، في البداية. لا يوجد XML. بالإضافة إلى ذلك، عناوين URL جميلة هل التعليق التوضيحي على مستوى Actionbean في Stripes 1.5 ، حتى تتمكن من فعل أشياء مثل @UrlBinding("/{$event}/{model}") أين /view/5 سوف يأخذك إلى "view"معالج الأحداث لكائن النموذج الخاص بك مع المعرف/PK من 5.

تنفيذ التدفق (المعالجات المتعددة على سبيل المثال): أنا أستخدم JSF 1.2 لذلك أستخدم أوركسترا Apache لنطاق التدفق (المحادثة).

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

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

لا يختلف اختلافا كليا. بدلاً من المكونات الموجودة على الفاصوليا [الإجراء] ، لديك الآن أنواع جافا أو مخصصة. يتم إنشاء ActionBeans لكل طلب وإلقاءها ، إلا إذا قمت بشيء مثل وضعه في الجلسة ، أو المعالج ، أو أي شيء آخر. هذا لطيف ، لأن جميع متغيرات المثيل يتم تعيينها على البيانات من النموذج ، وتستخدمها ، ثم رميها بعيدًا ، ولا يتعين عليها التعامل مع أي مشكلات تزامن مثل الدعامات. بعد أن تقوم بشيءك مع البيانات ، يتيح لك Stripes إرسال أداة توضيحية (حالة موافق) ، أو إعادة التوجيه ، أو البث (JSON ، ملف ، إلخ). يتم تنفيذ نمط إعادة التوجيه بعد النشر بشكل جيد مع فكرة نطاق فلاش (3/4 أسفل الصفحة).

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

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

دعم AJAX: العديد من المكتبات ذات الطرف الثالث (MyFaces ، IceFaces ، OpenFaces ، OtherPrefixFaces ...) لديها دعم قوي AJAX ويعمل بشكل جيد. حتى تلتقي مشكلة. الكثير من السحر هناك كذلك. من الصعب للغاية أن نجعلها تعمل إذا لم تنجح لكنك فعلت بشكل صحيح كما هو موضح في الدليل.

كانت هذه مشكلتي الكبيرة في طريقة JSF لفعل الأشياء. حتى لو حصلت على عنصر واجهة مستخدم ، فأنت لا تزال عالقًا مع تلك القطعة. باستخدام Stripes ، يمكنك استخدام أي شيء آخر وأكبر JQuery الذي تقدمه ، وطالما قمت بإرسال Get أو Post to the Server الصحيح ، تعرف Stripes ما يجب فعله به ويمكن بسهولة إرسال JSON مرة أخرى. أعتقد أن أطراف المكونات تتناسب مع مكانة منذ بضع سنوات أفضل بكثير عندما كان Ajax صعبًا ، لكن JQ يجعل الأمر سهلاً الآن.

عناوين URL سهلة الاستخدام: يقول الناس أن هناك بعض المكتبات لهذه موجودة. ويمكن القيام به مع المرشحات كذلك. لكنني لم أحاول قط. يبدو معقدًا جدًا للمظهر الأول.

urlbinding, ، الأمر سهل مثل ذلك.

Answer 2

إجابتي ليست هي التي تريد سماعها: لا تتحول من إطار عمل المكون إلى إطار العمل

لقد تحولت في الاتجاه الآخر بعد سنوات عديدة من تطوير إطار العمل ولم أعود أبدًا.

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

أنصحك بتجربة الويكيت ، من السهل جدًا التعلم (أسهل بكثير من JSF) ويتيح لك إعادة استخدام العديد من المكونات الموجودة أيضًا.