Чего это сразу «мучаются»? :-) Надо таки сравнение провести будет, только надо аккуратно метрики выбрать, по которым сравнивать, чтобы не забыть ни фичи CUBA, ни фичи Grails. Желательно на примере разработки приложения какого-нибудь. Если есть предложения, на каком примере это можно сделать — готов выслушать. Вышеупомянутый Bicycle Workshop пойдет, как думаете?
Ну вообще-то пост называется Разработка на CUBA — большой шаг в сторону от Spring? и это выглядит именно как противопоставление.
Заголовок — да. В статье я постарался показать, что не так страшен новый фреймворк, как его малюют. И таки шаг в сторону небольшой, все равно Spring пользоваться, в основном. Значит, не очень мысль донес.
Я писал, что мы сами используем платформу для разработки как коробочных продуктов, так и для софта на заказ. Так что команда разработчиков CUBA кровно заинтересована, чтобы багов было как можно меньше, иначе коллеги могут багрепорт с ноги сделать. Да, баги есть, куда же без них, только я не уверен, что при разработке такой же функциональности собственноручно их не будет.
По образцу того, как я делал Pet Clinic, можно ради эксперимента сделать приложение из CUBA учебника — Bicycle Workshop и посмотреть, сколько кода получится и сколько времени займет разработать это на Spiring/Spring Boot или ещё чем с такой же функциональностью.
Я не против таких доводов и не говорю, что Spring или Lombok плохо, а CUBA — хорошо. Мое мнение — если надо быстро сделать типовое приложение и всем будет все равно, как называются поля для аудита в БД, если их назначение понятно, то на CUBA это будет быстрее и, скорее всего, меньше кода. Пара интерфейсов в базовом класе — и готово. Если надо более сложных вещей, то есть Entity Listeners, там много чего можно навернуть.
Я же говорю, это не противопоставление, это дополнение. На включение кэша в CUBA уйдет не больше времени, чем если вы это будете делать вручную. Причем я в статье написал, что как раз можно использовать спринговый @Cacheable.
Права доступа — есть и в Vaadin-е, плюс Spring.
Вот тут есть риск выйти за вечер неспешного кодинга, мне кажется. Особенно, если это делать в первый раз. В CUBA в готовой админке можно сразу выдавать права доступа на формы, сущности и атрибуты.
Hot deploy обеспечивается JVM, правда если не сильно меняли классы. А CUBA может в hot deploy при изменении интерфейса классов?
Идеи примерно такие же, да. jHipster можно рассматривать как конкурента. Был ещё такой забытый проект AppFuse, тоже про генерацию заготовок. Но CUBA добавляет туда возможность надстройки и кастомизации, поэтому она «платформа», а не «генератор заготовок приложения». Можно сходить по ссылкам в п.2 раздела «Итого», там как раз про расширяемость.
Остается ещё написать админку с пользователями и ролями, сконфигурировать Spring Security, написать Entity-DTO преобразования, сверстать шаблон для главного окна приложения, сделать ролевой доступ к пунктам меню, сделать кэш данных и запросов, постраничный вывод данных, форму фильтрации. Потом ещё библиотеку репортинга вкрутить и добавить формы ввода параметров отчета. И да, если этот продукт будет коробочным, то ещё будет немного веселья с кастомизацией для разных заказчиков, нужно будет придумывать, как правильно это делать с наименьшей болью.
Vaadin, EclipseLink, Spring уже собраны вместе в платформе. Не надо тратить вечер неспешного кодинга на их прикручивание. При разработке на CUBA эти фреймворки и используются, приемы разработки там те же.
Disclaimer — CUBA не противопоставляется Spring Boot. CUBA можно рассматривать как Spring+ещё библиотеки, которые делают вашу жизнь проще при разработке типовых проектов.
Создаются классы предметной области и на них ставятся аннотации Table, Entity и.т.д.
Затем эти классы регистрируются в файле persistence.xml.
Руками каждый класс? Или хотя бы можно ограничиться только пакетом?
XSD для persistence.xml не разрешает указывать пакет (http://oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/index.html#2.2). Можно указать JAR файл, классы по отдельности и включить опцию «exclude-unlisted-classes», но она не работает для JavaSE persistence unit и, в теории, может принести что-то лищнее. CUBA Studio это автоматом делает, IDEA тоже может автоматизировать эту работу. И сущности делаются не так часто, так что неудобство минимальное.
Рекомендуется использовать аннотацию @NamePattern — аналог метода toString() для читабельного отображения сущностей в пользовательском интерфейсе.
А это есть в Lombok. В купе с прочим скрытием бойлерплейта.
@NamePattern не замена toString(), это дополнение для CUBA. Технически — можно использовать Lombok, мы его сознательно не тащим в платформу, чтобы не было лишних зависимостей и IDE без плагинов не сходили с ума.
Полезные маркер-интерфейсы, которые дают дополнительные возможности
Versioned, SoftDelete, Updatable, Creatable
Это всё умеет и Spring через аннотации, причём аннотации гибче интерфейсов — можно использовать удобные для тебя имена полей.
Version ставится над полем, в 90% случаев, я думаю, это поле будет называться version и дальше про него все забудут. Зачем нужен бойлерплейт?
То же самое можно сказать про @CreatedDate и @LastModifiedDate.
Скрипты для создания и обновления БД генерируются автоматически при помощи CUBA Studio.
Так умеет Hibernate, но я считаю что ручное написание скриптов даёт не только больше контроля, но и на порядок больше возможностей…
Возьмите Flyway/Liquibase — и в перёд. Хоть чистый SQL, хоть XML с валидацией, хоть DSL.
Это хорошее и правильное замечание и тема для отдельного исследования. В CUBA так исторически сложилось, что делали генерацию SQL, в те времена Liquibase не очень подошла. У меня есть задача взвесить все «за» и «против» переезда на одну из этих библиотек. Кроме того, скрипты SQL, которые генерирует CUBA, делаются в виде файлов и можно посмотреть, что было сгенерировано и даже поправить руками или дописать свое, если требуется, перед тем, как применять изменения. Это не черный ящик. Скрипты SQL попадают в codebase, коммитятся в Git и они вообще часть проекта.
Концепция “представлений” в CUBA может показаться несколько непривычной, но она достаточно легко объясняется.
Представление — это декларативный способ объявления атрибутов, значения которых необходимо извлечь из хранилища данных.
И это умеет Spring Data JPA: Projections
Есть нюанс: данные тянутся из базы все, а потом преобразуются спрингом. А в случае View из базы не выбираются ненужные поля. Т.е., если в сущности 100 атрибутов, а тебе на форме нужен один, то из базы вытащится 100, а потом Projection сделает DTO с одним атрибутом.
Дополнительно нужно зарегистрировать сервисы в файле web-spring.xml в модуле Web.
А в Spring Boot xml-файлы уже давно не нужны.
Да, верно, но там нет раздельного деплоя services и controllers из коробки, надо руками дописывать. И есть шанс, что при разработке такого механизма может получиться так, что потребуется XML файл, в котором будут прописаны сервисы, для которых надо делать прокси. А может и не потребоваться. У нас так получилось пока.
Сейчас ведется борьба с уменьшением XML, переходим на аннотации там, где возможно.
Тут или логическая ошибка или вы не с тем боритесь.
Боремся с тем, чтобы XML файлов было как можно меньше :-)
А поиграться — простое приложение «библиотека» и исходники к нему.
Заголовок — да. В статье я постарался показать, что не так страшен новый фреймворк, как его малюют. И таки шаг в сторону небольшой, все равно Spring пользоваться, в основном. Значит, не очень мысль донес.
По образцу того, как я делал Pet Clinic, можно ради эксперимента сделать приложение из CUBA учебника — Bicycle Workshop и посмотреть, сколько кода получится и сколько времени займет разработать это на Spiring/Spring Boot или ещё чем с такой же функциональностью.
Я же говорю, это не противопоставление, это дополнение. На включение кэша в CUBA уйдет не больше времени, чем если вы это будете делать вручную. Причем я в статье написал, что как раз можно использовать спринговый @Cacheable.
Вот тут есть риск выйти за вечер неспешного кодинга, мне кажется. Особенно, если это делать в первый раз. В CUBA в готовой админке можно сразу выдавать права доступа на формы, сущности и атрибуты.
Конечно, же, не все можно сделать через hot deploy. Даже JRebel не всемогущ. Подробно тут: doc.cuba-platform.com/manual-latest-ru/hot_deploy.html, чтобы комментарии не пухли.
Vaadin, EclipseLink, Spring уже собраны вместе в платформе. Не надо тратить вечер неспешного кодинга на их прикручивание. При разработке на CUBA эти фреймворки и используются, приемы разработки там те же.
XSD для persistence.xml не разрешает указывать пакет (http://oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/index.html#2.2). Можно указать JAR файл, классы по отдельности и включить опцию «exclude-unlisted-classes», но она не работает для JavaSE persistence unit и, в теории, может принести что-то лищнее. CUBA Studio это автоматом делает, IDEA тоже может автоматизировать эту работу. И сущности делаются не так часто, так что неудобство минимальное.
@NamePattern не замена toString(), это дополнение для CUBA. Технически — можно использовать Lombok, мы его сознательно не тащим в платформу, чтобы не было лишних зависимостей и IDE без плагинов не сходили с ума.
Это хорошее и правильное замечание и тема для отдельного исследования. В CUBA так исторически сложилось, что делали генерацию SQL, в те времена Liquibase не очень подошла. У меня есть задача взвесить все «за» и «против» переезда на одну из этих библиотек. Кроме того, скрипты SQL, которые генерирует CUBA, делаются в виде файлов и можно посмотреть, что было сгенерировано и даже поправить руками или дописать свое, если требуется, перед тем, как применять изменения. Это не черный ящик. Скрипты SQL попадают в codebase, коммитятся в Git и они вообще часть проекта.
Есть нюанс: данные тянутся из базы все, а потом преобразуются спрингом. А в случае View из базы не выбираются ненужные поля. Т.е., если в сущности 100 атрибутов, а тебе на форме нужен один, то из базы вытащится 100, а потом Projection сделает DTO с одним атрибутом.
Да, верно, но там нет раздельного деплоя services и controllers из коробки, надо руками дописывать. И есть шанс, что при разработке такого механизма может получиться так, что потребуется XML файл, в котором будут прописаны сервисы, для которых надо делать прокси. А может и не потребоваться. У нас так получилось пока.
Боремся с тем, чтобы XML файлов было как можно меньше :-)