Чи варто Грааль того вартий? [зачинено]

Це наполовину розмови, наполовину питання.

Чи варто користуватися Граалями? Я намагаюся розробити відносно простий веб-додаток, керований базами даних. Мій досвід роботи в Java, тому, природно, Grails здався хорошим вибором. Спочатку я думав використовувати Spring, JPA та Hibernate, але я вже використовував це раніше і стикався з усіма видами нудної конфігурації та кодування. Grails рекламує себе як вирішення цієї проблеми.

Моє найбільше розчарування в Граалях - це всі дрібниці, які не працюють. Я маю на увазі, що це працює не так, як інтуїтивно можна було б подумати, що мало б. По краях дуже шорстко. Я постійно стикаюся з проблемами. Іноді це через те, що я не розумію Grails - інколи я виявляв законні помилки Grails.

Одне з головних питань - відсутність належної інтеграції Eclipse. Існує плагін Groovy та Grails, але він не робить багато іншого, крім підсвічування синтаксису. Викликати Groovy з Java та навпаки дуже болісно налаштовувати . Відсутність хорошої підтримки IDE є серйозним наслідком.

Що трапляється, я сідаю, намагаючись розробити свій веб-додаток. Врешті-решт я усвідомлюю, що провів близько 85% дня, налагоджуючи проблеми, пов'язані з Граалем. Якщо це не проблеми Eclipse , то це жадібне завантаження , вибірка в поданні , один-ко-многим , дивною порожньому поведінку файлу помилка , дивну властивість / геттер помилка - це просто йде далі і далі. Це лише зразок питань, з якими я зіткнувся сьогодні. Моє останнє сидіння з Граалем породило цілу купу різних питань.

Я іноді замислююся, чи варто це робити. Мені цікаво, чи переживали це інші. Чи є люди, які насправді використовують Grails для продуктивного викручування веб-програми? Чи є інші основи для швидкої веб-розробки, які я повинен розглянути?

У нас була команда з 12 чоловік, всі досвідчені Java-розробники, які вивчили Grails з 0,6 B, і всі ми досі працюємо над проектами, заснованими на Grails. Я не хотів би повертатися до Java охоче, і ми всі з полегшенням зламали задню частину швидкого кудись за допомогою програми Grails.

Це була боротьба, це було непросто, і було / є розчарування.

Тим не менше, ми щось доставили дуже швидко, враховуючи наші постійні зусилля .. Є помилки, багато з яких мають обхідні шляхи.

Я чув про кілька випадків, коли розробники, які добре володіють Java, намагаються зануритись у глибокі, складні заклинання проектів Grails. Ми відмовились від усієї Java і пішли на чистий Грааль і Groovy. Ми переконалися, що почали все просто, максимально керовано та якомога практичніше розробили складність.

Врешті-решт ми створили щось величезне і складне, що працювало казково і робило це набагато швидше, ніж написання чистої версії Java / Spring / Hibernate; і це без гідної підтримки IDE та набагато гіршої ситуації з точки зору помилок, ніж сьогодні.

Що стосується підтримки Eclipse, єдиною реальною IDE, яка використовується для Grails / Groovy, є Intellij - підтримка Eclipse відстала, на жаль: я був любителем Eclipse і далеко не перетворювач Intellij - підтримка Grails / Groovy здуває все інше хоча.

Так, Грааль незрілий порівняно з Весною, можливо. Або в сплячку. І я б поклався на пари, що в перші 1,5 року свого існування вони були однаково загрожені питаннями.

Це те, що воно є, покладає на вас обов’язок, дбати про те, щоб ви зводили складність до абсолютного мінімуму, ретельно перевіряючи (на наш погляд) і поступово та обережно нарощуючи складність.

Як тільки ви залучите Spring / Hibernate до стека, швидкого вирішення коду з Java не існує. Складність, яку втілює Грааль, є відображенням власної складності Весни / Зимового сну. Якщо ви відчуваєте, що ваш час краще витрачати на це з чистою Java, я б не сперечався інакше .. У мене все ще є свої WTF, але тепер, коли крута крива навчання позаду мене, я думаю, що я ще дотримуюся Граалів.

Мені дуже подобається писати заявку на Грааль з двох причин:

• Мені не потрібно користуватися Java
• Я можу користуватися Java

Думаю, після ознайомлення з граалами людина робить свої справи дуже швидко та елегантно.

Так багато плюсів. Мінусом є продуктивність, яка вражає мене з двох аспектів: розгортання та розробка тест-драйву.

Мені не вдалося запустити більше 3 додатків grails на одному (орендованому) сервері, тому що я швидко досяг межі пам'яті та продуктивності. Просто включено занадто багато фреймворків.

Плюс, теструнер граалів не вартий такої назви. Коли я запускаю модульні тести, їх слід робити в одну мить, а не за 10-20 с. Тому я постійно описую ділову логіку на простому java, тому що можу перевірити її набагато швидше. Але я думаю, що це можна вирішити за допомогою кращої інтеграції в IDE (затемнення).

Я думаю, що підтримка Весни «Граалів» стане великим стимулом. Якщо хтось може перенести його через CRUD в Інтернеті, це ті хлопці.

Я також думаю, що це досягає критичної маси. Є кілька нових книг, які з’являться на ринку в 2009 році. Я думаю, це допоможе швидкості прийняття.

Я повністю погоджуюсь з оригінальними настроями плакатів.

Ми є магазином Java + Spring і скористались можливістю випробувати Grails. Спочатку ми створили дуже маленький тестовий додаток, який виявився досить простим у виконанні, і він працював досить добре. Основні проблеми, які ми мали тут, були пов’язані з відсутністю знань із Groovy та Grails.

Після цього успіху (підвищення довіри) ми вирішили спробувати зробити трохи масштабніший проект. Це було набагато болючішим досвідом. Як згадували інші, ми виявили всілякі помилки та проблеми, які не виявились одразу на поверхні. Цикли перезапуску програми стають надзвичайно болючими, і якщо у вас немає справді гарного охоплення тестом, це кошмар робити будь-які повторні факторингу.

Дійсно розчаровує відсутність коду без жодного повідомлення про помилку! Це просто не працює, і ви не знаєте чому?

Мені подобається простота використання плагінів для JMS, Quartz та Remoting. Покидає багато нудного XML.

Мені майже подобається GORM за його простоту, хоча у нас також було кілька проблем.

Мені не подобається вільно набраний характер Groovy, і той факт, що ти повинен запускати свою програму лише для того, щоб мати змогу виявити купу помилок, занадто нагадує мені PHP або Rails.

Врешті-решт ми запитуємо себе, чи можливо написати складну частину керованого програмного забезпечення за допомогою Grails ...

У нас є програма Grails, яка збирається увійти у виробництво .... так що ми побачимо.

Ми використовуємо grails + на веб-шарі + java з сплячим режимом та пружиною на сервісному рівні. Це класичні три шари (Інтернет, логіка, дані), де Інтернет є Граалями, а логіка реалізована в Java. Як зазвичай у Java, ми використовуємо об'єкти bean, що представляють дані між різними шарами.

Це працює досить добре, і це було найкращим рішенням для нашого випадку, оскільки об'єкти bean вже були там, а також структура бази даних. З нашого досвіду, я думаю, що grails має велике значення як рівень веб-презентації, але я б дотримувався Java, щоб писати бізнес-правила та зберігати дані програми - оскільки grails "це" java, вся інтеграція grails-java досить гарна прямо вперед.

Ми використовуємо eclipse для розробки програми grails, і це погана інтеграція, як люди сказали тут. Але, за пропозицією іншого розробника, ми запускаємо програму grails із командного рядка і використовуємо eclipse лише для збереження вихідних файлів, і це працює досить добре, оскільки додаток оновлюється на льоту.

Я все ще не відчуваю себе комфортно використовувати граали в інших місцях, ніж у презентаційному шарі.

У мене набагато більше досвіду роботи з Ruby on Rails, ніж у будь-якому іншому світі Java, тому я виходжу з іншої точки зору. Загалом, Грааль є набагато більш грубо навколо-краю , ніж Rails є, частково з - за його незрілості, а почасти тому , що вона спирається на два шалено складних структур з -під кришки (Spring і Hibernate). Rails також має набагато більшу спільноту.

Але Groovy як мова досягла величезних успіхів, і з ним приємно працювати. Завдяки вдосконаленням, здійсненим у Groovy 1.6, Grails є набагато приємнішим, ніж JRuby on Rails, і ви отримуєте надзвичайно хорошу підтримку XML через GPath. Є багато приємних функцій, які ви отримуєте, перебуваючи на JVM (наприклад, паралельність та безліч захищених кодів), але без необхідності морочитися з Java (мовою, яка мені не дуже важлива), тому я маю справді важко переконати себе використовувати щось на МРТ.

Однак, маю визнати, Python виглядає спокусливо.

Що стосується ваших проблем із Eclipse, я не можу допомогти. Я використовую Vim та Emacs, здебільшого тому, що я не витримую використання IDE. Однак для таких динамічних мов, як Groovy, Ruby та Python, я не думаю, що IDE дійсно приносять якісь реальні переваги, оскільки насправді немає місця для генерації коду або необхідності компіляції. Може, спробувати попрацювати без IDE на деякий час і подивитися, чи все гладше?

Отже, так, я думаю, що Грааль того вартий. Вони зробили справжню роботу, щоб налагодити роботу так само швидко, як і раніше, а команди Grails та Groovy справді дуже, дуже віддані.

Я повністю з тобою! Грааль все ще відчуває себе настільки грубим по краях, що це майже жарт порівняти його з Rails. Якби хоча б звітування про помилки було трохи кращим. Але, мабуть, це, мабуть, також пов’язано з величезною кількістю бібліотек, які вона використовує під обкладинками. Одне слово: стек! Я також не великий шанувальник підходу model-> db (Rails має db-> модель). Риштування також залишає багато місця для вдосконалення. Тоді "не потрібно перезавантаження" також не працює, як рекламується. (Я не впевнений, що гірше - постійно перезавантажуватись або іноді знаходити дивні способи поведінки, які зникають, коли ви перезапускаєтеся) І не запускайте мене в GORM. (Коли потрібні години, щоб знайти простий SQL, ви починаєте замислюватися, чи справді ця ORM заощаджує ваш час) Можливо, поки це просто.

Я маю на увазі: це все ще один з кращих варіантів фреймворку, коли ви приїжджаєте зі світу Java. (Стільки марного лайна там, що називає себе веб-фреймворком) ... він має потенціал. Я просто хотів би, щоб це не створювало поверх багатьох інших складних речей.

У будь-якому випадку - будемо сподіватися, що ці речі розберуться. На даний момент я ховаюся на playframework.org який також виглядає дуже гладким та перспективним.

Це буде того варте, коли вони закінчать плагін eclipse. Чим швидше, тим краще я скажу. Спроба продати groovy своєму шефу не буде простою, поки цього не станеться.

Я вважаю, що найбільшою перевагою Grails є те, що мені більше не потрібно дбати про базу даних - схема автоматично створюється / оновлюється, і постійність в основному робиться за мене (більше не потрібно писати SQL-запити). Це величезне полегшення. Інше, що досить приємно, це те, що після того, як ви зупинилися на шаблонах контролерів та подань, додавання нових об’єктів домену відбувається досить швидко. Хоча я підозрюю, що ви будете вносити постійні зміни у свої погляди принаймні, повертаючи їх до існуючих.

Що стосується IDE - здається, що IntelliJ - найкращий варіант, але я щасливий, використовуючи Netbeans 6.5. Я використовую MyEclipse для всіх інших розробок, але Netbeans просто зараз має кращу підтримку Grails.

Я був користувачем Eclipse до того, як почав користуватися Grails. Швидко стало очевидним, що це не збирається скорочувати. Тож я спробував Intellij та NetBeans. На той час Intellij був кращим щодо Groovy та Grails. Однак NetBeans був безкоштовним, і це зробило мене досить хорошим. З тих пір у всіх трьох вийшли нові версії або нові плагіни. Я все ще використовую NetBeans через вартість Intellij. З придбанням G2One компанією Spring Source одним із очікувань є більша підтримка Groovy та Grails у Eclipse. Це буде потрібно для посилення усиновлення.

Використовувати Grails для нового проекту - це чудово. Стільки багажу Enterprise Java більше не потрібно. Я можу уявити, що спроба перенести щось буде важкою, оскільки поки ви не зрозумієте, де сильні та слабкі сторони фреймворка, важко ефективно використовувати його. Обіцяно, що підтримка JSP стане простішою в Grails 1.1, я не знаю, чи хороша ідея використовувати бета-версію під час спроби знайти новий фреймворк. Тестування також пройшло серйозний перегляд для нової версії. Якщо час дозволяє, ви можете подумати про очікування, оскільки випуск 1.1 повинен бути дуже скоро.

Якщо у вас є можливість спробувати Grails в іншій IDE, починаючи проект з нуля, я думаю, ви побачите це в іншому світлі.

Я щойно почав використовувати grails у новому проекті ... відсутність необхідності писати БУДЬ-який xml-файл, але все-таки має силу Spring і Hibernate - це справді дивно.

Використовуйте IntellijIDEA для IDE, хоча я насправді виявив Грааль через IDE (хоча я можу бути упередженим, я ненавиджу затемнення).

Цілком. Існує настільки багато фреймворків Java, що планка встановлена ​​досить високо для новачків, і це свідчення Grails, що він зміг піднятися вище в такому переповненому просторі.

У нього все ще є кілька гострих країв, але це лише питання часу, поки їх не згладять, базовий проект ДУЖЕ вартий того.

Граалі можуть бути великими для вашого типу програми (на основі численних файлів, створених під час першої ініціалізації, та ресурсів, які потрібно). Якщо ви шукаєте щось просте, Граали можуть бути не тим, що ви шукаєте. Якщо ви шукаєте щось просте і працює, поки що, на мою думку, django може добре виконати вашу роботу. Погляньте, наскільки просто (скільки файлів потрібно) створити CRUD-програми з його підручника . Відтепер ваші програми можна (відносно) легко масштабувати, коли ваші потреби та вимоги зростають.

Я не впевнений, що вони коли-небудь зможуть зробити Грааль правильним, ви знаєте. І по праву я маю на увазі адресу всіх деталей (малих і великих), що зрештою змушує його почуватися крихким і крихким. Я навіть не впевнений, що за цим стоїть справжня команда розробників (мається на увазі більше 2 осіб).

Кожного разу, коли я переглядаю функцію моїх проектів Grails, намагаючись щось покращити, це той самий робочий процес: все розпадається, тоді це сотня тестових циклів "google", тоді ви з'ясовуєте причину, через яку не можете зробити що ти хочеш, а ти робиш щось інше.

Зрештою, ви розчаровані, бо навіть не хочете торкатися нічого, що біжить. А речі, які не добре, ти їх кидаєш!

Я розглядаю можливість переходу на Rails через JRuby. Це може бути найкращим з обох світів: здатний веб-фреймворк з активною та великою спільнотою, віддана команда розробників, платформа, яка не базується на сумнівних та складних фреймворках, таких як Spring або Hibernate, швидкий та амбіційний цикл випуску. І JRuby, бо, чесно кажучи, стільки активів Java у моєму рюкзаку, я не можу їх просто викинути.

Якщо ваш досвід у Java, як ви говорите. Вам слід поглянути на Play Framework - це веб-фреймворк, натхненний Ruby on Rails з дуже коротким циклом розробки - просто збережіть вихідний файл Java та оновіть веб-браузер. А якщо ви хочете спробувати іншу мову, у Play Framework є модуль, який дозволяє замість цього використовувати Scala.

Мені подобається Play Framework, оскільки це легко зрозуміти і має хорошу продуктивність. Ви також можете використовувати JPA та Hibernate для ORM-шару, якщо хочете.