أي تجربة مع "Play" Java Web Development Framework؟ [مغلق
https://stackoverflow.com/questions/1597086
-
22-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد تعثرت للتو على إطار عمل جافا الجديد التالي: العب
http://www.playframework.org/documentation/1.0/home
مع هذه القائمة المذهلة من الميزات ، أنا مندهش إلى حد كبير لأنني لم أسمع بها من قبل ...
يبدو أن تطوير الويب Java وعد به الأرض ...
هل حاول أي شخص ذلك؟ أي تجربة حقيقية معها؟ هل تعتقد أن الأمر يستحق دراسته؟
المحلول
وأنا أتفق مع جيسون على أن المسرحية قد تكون أفضل من الكأس. مع أربعة مشاريع Grails تحت حزامي (يسبقه مشروعين نسيج ومشروع واحد الويكيت) ، أنا أبحث بجدية في اللعب بعد ذلك.
أحد الأشياء التي اعتقدت أنها كانت رائعة في Grails هو أن "كل شيء رائع". وهذا يعني أنك تستخدم Groovy لكتابة كل شيء (باستثناء HTML و CSS) - المجالات ، وحدات التحكم ، والخدمات ، وقوالب الصفحة (GSP) ، ومكتبات العلامات ، و API السبات (GORM) ، واختبارات الوحدة (Gunit) ، و Build Scripts ( جانت). يمكنك حتى كتابة نصوص الصدفة في مروعة. لذلك ، بدا أن القدرة على ترميز جميع جوانب التطبيق باستخدام لغة واحدة مرة أخرى مثل التبسيط الذي كان متأخرًا منذ فترة طويلة - حيث عاد إلى أيام كتابة تطبيقات سطح المكتب بلغة واحدة مثل C ++ أو Delphi. ومع ذلك ، فقد تعلمت أن حجم واحد لا يناسب الجميع هنا.
لأحد ، دعم IDE لـ Groovy ليس رائعًا. يقوم Intellij بأفضل وظيفة ، ولكن مع كونها ديناميكية رائعة ، يمكن أن تذهب إلى هذا الحد. أدوات إعادة التجهيز لا (لا يمكن) التقاط كل شيء ، لذلك لا يمكنك الوثوق بها بنسبة 100 ٪. هذا يعني أنه يجب أن تكون متيقظًا بشكل خاص مع اختبار الوحدة. هنا مرة أخرى ، نظرًا لأن Grails تعتمد كثيرًا على "السحر" الديناميكي الذي يحدث في وقت التشغيل ، يجب أن تعتمد اختبار الوحدة في Grails على طبقة ساخرة واسعة لمحاكاةها ، وأن الطبقة الساخرة ملتوية. المسألة الثالثة هي أن الكثير من ما يسمى الرمز الرائع الذي تكتبه هو في الواقع رمز باللغة الخاصة بالمجال (DSL). (لجعل قصة قصيرة طويلة ، تكون DSLs رائعة في اليد ، وتستفيد من حقيقة أنه في حالة رائعة والكثير من بناء الجملة اختياري.) تستخدم Grails DSLs مختلفة لمختلف التكوينات ، ورسم خرائط URL ، وما إلى ذلك. كيف تحدد إعدادات Log4J ، على سبيل المثال ، لا تبدو مثل كيفية تحديد مصادر البيانات ، ولا يبدو أن Java النقي الذي يستند إليه Groovy. لذا ، فإن وعد "كل شيء رائع" ينهار على أي حال.
هذا هو الحال ، أرى من أين يأتي فريق اللعب.
العودة إلى Java العادية للمجالات ، وحدات التحكم ، والخدمات ، والابتدائي أمر منطقي. الكتابة القوية تعني أن IDE يمكن أن تساعد بشكل موثوق في Inteli-Sense ، والتنقل في الكود ، وإعادة التهيئة ، وما إلى ذلك (وبالتالي لا تحتاج إلى دفع ثمن Intellij إذا كنت راضيًا عن Eclipse) استعادة دعم الأدوات القوية يبدو وكأنه صفقة جيدة بالنسبة لي الآن. سوف نرى.
يعجبني أنني ما زلت أتمكن من استخدام Groovy في قوالب الصفحة. أخشى أن ينتهي بي الأمر إلى وضع المزيد من الكود في القوالب أكثر مما ينبغي.
ليس لدي أي خبرة مع JPA ، لكن يبدو أنه قريب جدًا من ما يفعله Gorm بالنسبة لي ، لذلك هذا رائع.
إن دعم الربيع للـ IOC في Grails شفاف تمامًا في حين أن دعم Play يبدو ضئيلًا ؛ ومع ذلك ، أعتقد أن IOC مفرط في الاستخدام ، وأنا على استعداد تمامًا لتسليم رمز الربيع XML في مناسبة نادرة أحتاجها حقًا. (أحد أسئلتي المفتوحة هو أنني أفترض أن JPA لديه دعم المعاملات وهذا هو السبب في أن اللعب لا يحتاج إلى الربيع لذلك مثل Grails ، لا؟)
لم أكن أبدًا من محبي Python ، لذلك شعرت عندما قرأت أن المسرحية تستخدم Python لنصوص البناء الخاصة بها. لكنني أوافق على أن البرامج النصية GANT 'GANT' تعمل بطيئة جدًا. بالإضافة إلى أنني أجد أنه على الرغم من أن Gant يعد تحسناً كبيرًا على XML Ant ، إلا أنه لا يزال من الصعب لف رأسك حول مفاهيم النمل. البرامج النصية GANT GANT معقدة جدا. لذلك ، سأذهب إليه بعقل متفتح.
يبدو أن نموذج "وحدة التطبيق" ليكون مثل طراز "المكون الإضافي" ، بحيث يكون رائعًا.
أنا معجب تمامًا بوثائق اللعب التي قرأتها حتى الآن. كان لدي عدد كبير من الأسئلة التي تسير ، ولكن تم الرد على نصفها مباشرة من الخفافيش.
سأقوم بإبلاغ مرة أخرى لاحقًا بينما أغوص أعمق.
نصائح أخرى
لقد حاولت اللعب وأنا معجب: إنه يقوم بعمل رائع في تقديم نموذج تطوير مفيد أبسط بكثير من معظم الأطر ". أكثر من أي شيء آخر ، فإن قدرة وقت التشغيل في "وضع التطوير" لتحليل ملفات .java مباشرة تستحق الكثير: ما عليك سوى إعادة تحميل صفحة الويب في المتصفح دون تشغيل برنامج نصي بناء أو في انتظار إعادة النشر يستحق الكثير من سرعة التطوير. رسائل الخطأ الموضحة في المتصفح جيدة حقًا أيضًا.
شيء آخر أثار إعجابي هو الجمالية العامة: ربما يكون تطبيق البرنامج التعليمي جيدًا بالفعل (كل من الكود وتصميم صفحة الويب) ، ولكن هذا يمتد إلى الإطار بأكمله ، واجهة برمجة التطبيقات وكذلك الوثائق.
بعد الحث من زميل نظرت إليه ، تابعت البرنامج التعليمي ، وحصلت على مدمن مخدرات. إن الحصول على ملاحظات فورية في متصفحك يعني أنك لست مضطرًا لاستخدام IDE. أحب Eclipse ، لكن دعنا نواجه الأمر: بعد إضافة بعض الإضافات ، فإنه ليس مستقرًا مثل محرر نص بسيط. على جهاز Mac مع TextMate ، يمكنك حتى النقر على رسالة الخطأ في متصفحك وينبثق Textmate مع المؤشر على هذا السطر.
يتم أيضًا إجراء الاختبار في اللعب بشكل جيد ، مع زر واحد اضغط على اختبارات الوحدة والاختبارات الوظيفية والاختبارات القائمة على السيلينيوم.
اللعب مثير لأنه لا يزال صغيرًا وغير معقد. يستخدم فقط النمل للبناء والقيام بذلك في 25 ثانية. المساهمة في الوثائق الجميلة هي مسألة تحرير ملفات .Textile وإعادة تحميل المستندات في أي تطبيق تشغيل.
هذه هي الطريقة التي انتهيت بها من السعي لترجمة البرنامج التعليمي لاستخدام Scala ، إضافة إلى دعم Scala عند الحاجة للحصول على ذلك لطيف قدر الإمكان.
يعجبني ذلك ، أنا أستخدمه في مشاريع صغيرة وحتى الآن يبدو مثاليًا لهذا المنصب. ومع ذلك ، هناك شيء واحد أفتقده كثيرًا أنه تم استبعاده عن قصد: فصل خدمة الخدمة/DAO/نموذج! الوثائق تقول ذلك بوضوح ، أحد أهداف اللعب هو تجنب "نموذج بيانات الفقر":http://www.playframework.org/documentation/1.0.1/model
ولكن في تجربتي ، يوفر فصل الخدمة الكلاسيكية/DAO/Model Layers أطنانًا من وقت التطوير عندما يحتاج التطبيق إلى إعادة بناء! مع اللعب ، أنت عالق مع أساليب ثابتة تعتمد على إدارة المعاملات الخاصة باللعب والخصائص ...
ومع ذلك ، فإن العديد من الإبهام ل: سرعة التطوير ، ونظافة الكود ، وفي النهاية ... متعة!
لقد استخدمت Grails و Tapestry 4/5 و Java/JSP المستقيم/الربيع/السبات.
أعتقد أن هذا يسير في الاتجاه الصحيح لأول مرة منذ فترة طويلة. كانت Grails خطوة أولى جيدة حقًا ولكن اللعب! يبدو وكأنه شيء يمكن أن يكون له أرجل حقًا. دعم Scala يأتي في 1.1. إذا كانت هناك فرصة لإمكانية كتابة وحدات التحكم الخاصة بي/المجال في Clojure ، فأنا أباع ؛)
منذ عام واحد وعدم وجود خطأ مرئي بعد 18 إصدارًا صغيرًا ، نستخدم اللعب! 1.2.4 في تطبيق "الغياب" في الإنتاج ، تطبيق إنترانت للمدرسة (الجهات الفاعلة:> 100 مدرس ،> 700 طالب ، فريق الإدارة). تمت كتابة جانب العميل مع Flex 4.6 من Adobe (مناظر جميلة جدًا). يتم إرسال البيانات وتلقيها بتنسيق AMF3 (وحدة القرفة). نحن نستخدم طبقة DAO بسيطة استنادًا إلى JPA Eclipselink و MySQL لـ DB. يتم تخزين التطبيق على خادم Linux الظاهري. أنا مطور مشجعي للغاية من أجل بساطته ونهجه الإنتاجي للغاية.
أنا أحب مظهر اللعب ، لكنني لم أحاول ذلك. من المسح من خلال المستندات ، كان الشيء الذي برز هو الاستخدام الكثيف للطرق الثابتة. من وجهة نظر اختبار الوحدة ، يجعل هذا الأمر دائمًا أكثر صعوبة (أفكر في الاستهزاء) ، وهو خروج عن نهج OO-Everywhere في تطور Java النموذجي. ربما هذه هي النقطة ، لكنها مجرد شيء جعلني أقل حماسًا ...
أقوم حاليًا بإنشاء تطبيقات الويب في العمل باستخدام إطار العمل الذي يقوم بمعالجة البيانات الضخمة. يجب أن أقول إن السرعة التي تقدمها اللعب وحدها مهمة وأكثر مما يمكن أن يوفره ROR. علاوة على ذلك ، فإن Play هو إطار قائم على Java ، وبالتالي يمكن القيام متعدد الخيوط بسهولة. التالي هو الأداء الهائل الذي تحصل عليه عند استخدام وحدات تعتمد على Java مثل Japid و Netty إلى جانب Play. إنه مثل كمية لا نهاية لها من التغيير والتبديل يمكن القيام بها للأداء. يجب أن أحاول في رأيي.
أنا أستخدم اللعب في مشروع صغير ، ويبدو أنه بالضبط ما قالوه. لكن ميزة واحدة أعتقد أنها يجب أن تكون حاضرة افتراضيًا في الإطار: القدرة على العمل مع أكثر من مصدر بيانات واحد (على سبيل المثال ، استخدم أكثر من مخطط قاعدة بيانات واحد). هذه هي الميزة المفقودة الوحيدة التي وجدتها حتى الآن.
التحيات ، Uilian.
