سؤال

الكؤوس مقابل القضبان.الذي لديه دعم أفضل؟وما هو الخيار الأفضل لتطوير التطبيقات متوسطة الحجم؟والأهم من ذلك أيهما يحتوي على المزيد من المكونات الإضافية؟

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

المحلول

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

بعد قولي هذا، ما زلت أتساءل أيهما أختار.كما كان يقول توم، إذا كنت تعتمد على Java، فلا يزال بإمكانك استخدام JRuby - لذلك لا ينبغي أن تكون إعادة استخدام Java هي المعيار الوحيد لديك.

نصائح أخرى

أعتقد أنك إذا كنت أحد مطوري Java وترغب في الوصول إلى جميع مكتبات ووظائف Java الموجودة في المؤسسة...اذهب مع غرايلز.

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

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

أقول الكؤوس لأن هناك الكثير من مكتبات جافا هناك.لكنني متحيز بعض الشيء لأنني أتيت من خلفية جافا.

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

يعتمد ذلك على مهاراتك في التعامل مع Ruby و/أو Groovy، وما إذا كان لديك أنظمة Java قديمة للتعامل معها، والمكان الذي تريد نشر تطبيقاتك فيه.

لقد شعرت بسعادة غامرة في البداية مع ريلز.في ذلك الوقت، لم يكن هناك خيار للنشر على خوادم التطبيقات في العمل نظرًا لأن العمل كله يعتمد على Java.لقد تغير هذا.لم أستطع التخلي عن بنية Java الأساسية وتطبيقاتها الموجودة بالفعل والتحول إلى Ruby، على الرغم من أنني اعتقدت أن Rails كانت رائعة.تعمل Grails لأنه يمكننا مزج Groovy ومطابقتها مع حلول Java الحالية.

خارج نطاق العمل، من الأسهل العثور على استضافة Ruby عند الطرف الأدنى من نطاق الأسعار.نظرًا لأن Grails يستخدم الكثير من مشاريع Java الحالية، فإن ملفات .war، حتى بالنسبة للتطبيقات الصغيرة، تميل إلى أن تكون كبيرة الحجم.إذا كان لديك خادم مخصص، فهذه ليست مشكلة ولكن محاولة التشغيل على استضافة مشتركة بذاكرة وصول عشوائي (RAM) سعة 128 ميجابايت لن تنجح.

عام 2008 هو عام كتب Groovy and Grails ولكن لا يزال هناك العديد من موارد Rails المتاحة.

بناءً على معاييرك المحددة، قد يكون Rails إطارًا أفضل للتعلم.إذا كان لديك أي معرفة أو أمتعة بالجافا؛-)، فيجب عليك إلقاء نظرة على Grails.

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

عندما بدأت مع Rails، كان هناك عدد قليل جدًا من المواقع التي تستخدمه وكان التوثيق فظيعًا.كان هناك Railscast الذي كان رائعًا وrailsforum.com، ولكن أي شيء خارج عن المألوف، أنت وحدك.كان نشره بمثابة كابوس، ولم يكن استخدام المجموعات الهجينة جاهزًا للإنتاج حقًا.وهذا مختلف تمامًا الآن كما يرى الجميع، فهو أكثر نضجًا وانتشارًا في كل مكان.

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

شيء آخر عليك أن تنظر إليه هو IDE.إذا كنت مرتاحًا مع Eclipse، فإن Eclipse-STS for Grails يمنحك كل الأجراس والصفارات.ما زلت أرى الكثير من مطوري Rails يستخدمون textmate، على الرغم من أن Rubymine قد خطت خطوات كبيرة (الإصدار المبكر من Rubymine كان يستخدم لإيقاف نظام Ubuntu الخاص بي).

خلاصة القول، كلاهما إطار عمل MVC رائع.RoR أكثر نضجًا ولديها الكثير من المطورين.Grails هي حيث كان RoR قبل 3-4 سنوات، لكنني أرى التقدم أسرع كثيرًا.أتمنى أن يساعدك هذا.

بالنظر إلى كيف تم شراء الأشخاص الذين يصنعون Grails من قبل مصدر Spring بالأمس، أود أن أقول Grails.

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

الكؤوس على طول الطريق!

سأختار Grails لأنني أحب منهجها (حدد فئات المجال الخاص بك واطلب من Grails إنشاء كل شيء آخر) بشكل أفضل من Rails (إنشاء جداول قاعدة البيانات وجعل Rails تولد كل شيء آخر).إذا كنت أحد مطوري Java، فسوف يعجبك أيضًا أن كود Java هو كود Groovy صالح، وفئة Groovy هي فئة Java، لذا يكون التكامل سلسًا في كلا الاتجاهين.

هل بإمكاني أن أقترح ميرب؟إنه قائم على حامل، ونموذجي، ولا يعتمد على ORM، وقد تم تصميمه للسرعة من الألف إلى الياء بواسطة Ezra Zygmuntowicz.لقد بدأت تكتسب بعض الحرارة الآن...

باعتباري مطور Grails قادمًا من Java، فقد أحببته منذ المرة الأولى.

الآن، بدأت في التنقيب في Rails وأواجه مشكلات مع الأحجار الكريمة.على الرغم من أن إعداد اتصال MySQL مع Grails كان بسيطًا جدًا، إلا أنني ما زلت أجد صعوبة في جعله يعمل مع Rails.

الامر gem install mysql لا يعمل، على ما يبدو لأنه ليس لدي XCode مثبت.

لولا مشكلة استهلاك الذاكرة، لقلت أن Grails مثالي.

تعتبر Rails أكثر شيوعًا، ولكنها أقل مرونة.لا تزال Grails تتغير بسرعة، ولا تمتلك نفس النظام البيئي للمطورين، والوثائق ليست ناضجة تقريبًا، ولكنها ستعمل في بعض المواقف التي لن تنجح فيها Rails.

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

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

لقد تحولت أخيرًا إلى استخدام مجموعة أدوات الويب من Google لأنني لم أكن بحاجة إلى قاعدة البيانات حقًا.

أعتقد أن Grails وGroovy يحملان وعدًا، لكن تجربة المستخدم في العمل معهم مرهقة في الوقت الحاضر (كان الوقت الحاضر في الربيع الماضي).

أعتقد أن ذلك يعتمد على البيئة التي تعمل فيها إلى حد ما.

يبدو أن Grails تحظى بقبول أكبر على مستوى الشركات.

تتمتع Rails بأجواء Koolaid، وهي مقبولة جدًا للشركات الناشئة التي ليس لديها أنظمة قديمة.

أنا شخصياً أستخدم كلاهما.على الرغم من أنني بدأت للتو في عالم Grails - إلا أنني أحب أن تكون المصادقة/الترخيص أسهل في Grails - مكون إضافي بسيط؛شيرو.يعجبني أن Rails لا يعتمد على JVM، ولا يستغرق بدء التشغيل دقيقة أو نحو ذلك.

أجد أن إعداد BDD/Cucumber داخل Rails كان أسهل بكثير، ولكن قد يكون ذلك لأن هذا هو ما أشعر بالارتياح تجاهه!من المؤكد أن هناك جهودًا تبذل في عالم Grails (cuke4duke وما إلى ذلك) لتسهيل ذلك، كما يوجد مجتمع نشط يعمل على تطوير Grails.

فقط 2p ·

جرب كلاهما :)

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