SpringSource (нині VMWare) має дві дуже схожі технології: Grails та Spring Roo. Я використовую Grails, але я бачу, що SpringSource активно працює над чимось, що є конкурентом для цієї технології, і це викликає у мене занепокоєння щодо майбутнього Grails.
Хтось знає, як ці технології пов’язані, чи будуть вони об’єднані, чи одна з них буде залишена?
Крім того, чи є якісь важливі технічні відмінності між Grails і Roo?
Відповіді:
Мета SpringSource - зробити його максимально швидким та простим для людей для створення, запуску та управління рішеннями на основі Spring. У нас є як Grails, так і Spring Roo, тому що ми глибоко піклуємося про продуктивність розробників, і, безперечно, обидва ці інструменти дають серйозний поштовх тому, що команди можуть досягти на вершині Spring.
Ми маємо обидві технології, оскільки Roo і Grails дуже сильно відрізняються на філософському та реалізаційному рівнях (як це вже зазначалося в інших відповідях). Кожна технологія наближається до своєї основної мови (Java або Groovy) та операційної моделі (часу розробки або виконання) із філософією: "як зробити пропозицію цінностей неймовірно доброю, використовуючи цю комбінацію мови та операційної моделі?". Таким чином, ви побачите, що кожна технологія приймає інший стиль, який максимізує цю комбінацію (Java Roo + Dev-time або Grail's Groovy + Runtime) та відповідні переваги.
Ці відмінності насправді дуже позитивні, оскільки вони означають, що громада Весни може вибрати, який «смак» рішення щодо продуктивності їм більше подобається. Незважаючи на те, що ці початкові відмінності щодо вибору мови та виконання / роботи під час розробки одразу очевидні, вибір Grails або Roo також поширюється на більш тонкі міркування, такі як використовувані технології за замовчуванням, модель взаємодії з користувачем, підтримка IDE, залежності, стандарти, дорожня карта, розширення тощо. Майже всі ці відмінності є природним наслідком досягнення найкращого в галузі рішення для певного стилю мови.
Наша найкраща порада - розглянути обидва рішення. У кожного є свої солодкі плями, але між ними є відмінності, які покращать ваш загальний досвід із використанням тієї чи іншої технології в певному контексті. Обидві довідники докладно описуються відповідні переваги з кожного розчину . Звичайно, пам’ятайте, що витрати часу на випробування обох є мінімальними. За 10 хвилин ви можете побудувати проект в Roo або Grails, тож спробуйте і подивіться, що для вас здається більш природним, враховуючи ваші конкретні передумови та потреби проекту.
Основна відмінність полягає в тому, що Roo - це суттєвий фреймворк Java, тоді як Grails використовує Groovy, а також Java. Обидві побудовані на основних бібліотеках Spring і використовують популярні бібліотеки Java з відкритим кодом.
Це питання було задано ще при оголошенні Roo, а Грем Роше (керівник Grails) каже, що обидва фреймворки мають місце в Spring і підтримуються однаково.
Якщо що, я думаю, що у Грайля світліше майбутнє, ніж у Ру. Я люблю розвиватися з ним і не бачу жодних мінусів, якщо це не є чистою Java.
Грааль і Ру дуже відрізняються. Перша велика відмінність - мова, якою користуються. Хоча ви можете писати код Groovy, як традиційний код Java, вам все одно потрібні залежності Groovy для запуску програм Grails. Щоб бути максимально продуктивним у Grails, вам також потрібно мати уявлення про функції в Groovy, які в даний час не є частиною Java, такі як Closures. Інша відмінність - це філософія, яку основи беруть до генерації коду. Grails генерує багато методів під час виконання, тоді як Roo генерує їх на запит під час процесу розробки. Roo не має магічного захоплення для використання аспектно-орієнтованого програмування, і ви можете переглянути весь код, який Roo генерує. Наприклад, у Roo ви повинні використовувати команду, щоб вона генерувала динамічні методи пошуку, такі як findByBook (), а потім переглядала згенерований код у файлах .aj. У Grails метод findByBook () створюється під час виконання, і ви не можете переглянути створений код. Roo також дозволяє припинити використання фреймворку, якщо ви вибрали, продовжуючи мати запущений додаток, об'єднавши весь згенерований код у звичайні файли .java. Тоді ви не маєте залежностей від жодної бібліотеки Roo ні під час виконання, ні під час проектування. Якщо ви вирішите, що вам не подобається Grails, немає можливості припинити використання фреймворку, продовжуючи при цьому функціонувати додаток.
ІМО ці два не дуже схожі. Незважаючи на те, що є подібності, наступні суттєві відмінності:
Ій дуже схожий на систему командного рядка Grails '(наприклад create-app, create-domain-class, test-appкоманди типу знайдені в Grails). Я не був би здивований, коли побачив би певне "перехресне запилення" між цією частиною фреймворку Грайлів та Roo.
Бен Алекс із SpringSource розповідає про Роо в цьому інтерв'ю, і його запитують про Грайля проти Ру. Основна відмінність, крім використання різних мов (Groovy проти Java, як згадувались інші), полягає в тому, що Roo - це головним чином інструмент часу розробки, а Grails більше задіяний у середовищі виконання.
Я бачив деякі коментарі до списків розсилки Граалів, які вказували на те, що автори вірили, що Ру існує лише як сходинка до Грааля! Однак я особисто розглядаю можливий перехід від Grails до Roo. Я думаю, що головна відмінність полягає в динамічній та статично набраній мовах - для мене це величезна. Мені подобаються багато можливостей Grails, але я віддаю перевагу підтримці IDE та перевірці часу компіляції статично набраної мови. Деякі інші відчувають прямо протилежне, звідси коні на курси. Тим не менш, статичні канавки в даний час значною мірою розробляються, тому хто знає, яке майбутнє.
У нас була вимога, коли ми мали застосування у виробництві і було розроблено навесні MVC, і швидкість розробки нових функцій була повільною. Нам довелося дослідити альтернативні рамки, такі як Grails та Roo. Я особисто витратив близько місяця, досліджуючи, який з них був кращим.
Якщо ви хочете побачити деталі аналізу, відвідайте @ http://krishnasblog.com/2012/05/08/roo-vs-grails/
Ми дослідили наступні особливості як у цих, так і нижче - це наші висновки. Остаточний вердикт ми не впевнені, що використаємо жоден із них, ми все ще вивчаємо