Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Когда существуюет 100+ табличек БД — 100+ различных контролллеров с 10-20 сервисами и сложной бизнесс-логикой, поддерживать генерируемый код очень сложно и без хорошего покрытия тестами это приводит к различным побочным эффектам. Это anti-DDD проектирование.
Гораздо проще загрузить схему БД и создать контроллер в с маршрутами
C него можно реализовать полноценный RESTful сервис, который будет загружать правила авторизации (c Authorization сервиса) по принципу «запрещено всё, что не разрешено явно», и даст возможность загружать схему данных (типа JSON-Schema) в форнтенд для автоматизческой генерации основных правил валидации, предоставит интерфейсы для реализации сервиса учёта (Accounting) и аутентификации (Authentication).
OPTIONS методы subscribe и changed используются для оповещения об изменениях (JSON-patch, можно и по comet'у, можно и по вэбсокетах) и блокировке сущностей.
Это SOA по DDD, без генерации тонны копи-пасты.
Гораздо проще загрузить схему БД и создать контроллер в с маршрутами
GET /{entityname}/{id}
GET /plural({entityname})
POST /new/{entityname}/
PUT /edit/{entityname}/{id}
DELETE /remove/{entityname}/{id}
OPTIONS /{entityname}/schema
OPTIONS /{entityname}/caching
OPTIONS /{entityname}/rights
OPTIONS /{entityname}/{id}/subscribe
OPTIONS /{entityname}/{id}/changedC него можно реализовать полноценный RESTful сервис, который будет загружать правила авторизации (c Authorization сервиса) по принципу «запрещено всё, что не разрешено явно», и даст возможность загружать схему данных (типа JSON-Schema) в форнтенд для автоматизческой генерации основных правил валидации, предоставит интерфейсы для реализации сервиса учёта (Accounting) и аутентификации (Authentication).
OPTIONS методы subscribe и changed используются для оповещения об изменениях (JSON-patch, можно и по comet'у, можно и по вэбсокетах) и блокировке сущностей.
Это SOA по DDD, без генерации тонны копи-пасты.
Забыл добавить что для many-to-many связей и one-to-many можно добавить обработку batch запросов в виде
p.s. Это тема для отдельной статьи, которую мне уже не хочется писать после комментариев к предыдущей.
POST /add/plural({entityname})/[to|for]/{entityname}/id
DELETE /remove/plural({entityname})/from/{entityname}/id
p.s. Это тема для отдельной статьи, которую мне уже не хочется писать после комментариев к предыдущей.
К опросу: Нужно понимать, что генераторы генераторам рознь. Одни генерируют «заглушки» и «скелеты», подразумевая, что основной код будет писаться руками, другие генерируют работоспособный код для типовых задач, подразумевая его расширение для нетиповых, третьи же «думают», что всё предусмотрели и правки кода пользователем вообще не требуются (утрирую, но не сильно).
Прежде чем использовать генератор в серьезном проекте, нужно понять (и убедиться на практике, что понял правильно) его назначение, предполагаемые методики расширения/изменения, поведение при попытках (включая случайные) перегенерации и прочие нюансы. В одних случаях сгенерированный код можно даже не хранить в репозитории, генерируя его при деплое, а в других его нельзя даже как-то изменить без риска, что при случайной перегенерации все изменения будут затерты. А уже поняв это, нужно решать можно ли использовать генератор в текущем проекте.
Прежде чем использовать генератор в серьезном проекте, нужно понять (и убедиться на практике, что понял правильно) его назначение, предполагаемые методики расширения/изменения, поведение при попытках (включая случайные) перегенерации и прочие нюансы. В одних случаях сгенерированный код можно даже не хранить в репозитории, генерируя его при деплое, а в других его нельзя даже как-то изменить без риска, что при случайной перегенерации все изменения будут затерты. А уже поняв это, нужно решать можно ли использовать генератор в текущем проекте.
По поводу опроса — здесь речь шла о тех, которые генерируют работоспособный код для типовых задач, как описанный здесь Lionframe.
Есть понятие Scaffolding'a — это процесс который генерирует для всех табличек в базе по контроллеру, шаблону и тесту для MVC приложения.
Понятное дело что это всё нужно будет потом переписывать под себя, в том числе и часть шаблонов генератора. Как показывает моя практика, scaffolding в lionframe, или Grails, допилить достаточно просто.
В этом комментарии описываются абстрактные генераторы в вакууме — напишите конкретно о решениях которые имеются ввиду, иначе это просто ваше субъективное суждение не обоснованное практикой.
Понятное дело что это всё нужно будет потом переписывать под себя, в том числе и часть шаблонов генератора. Как показывает моя практика, scaffolding в lionframe, или Grails, допилить достаточно просто.
В этом комментарии описываются абстрактные генераторы в вакууме — напишите конкретно о решениях которые имеются ввиду, иначе это просто ваше субъективное суждение не обоснованное практикой.
Основая причина появления этого продукта, мне думается, не очередная стопицотая проверка полезности генератора рутинного (!) кода. Скорее тут речь об инкапсуляции контроллеров внутри бандла. (SyliusResourceBundle). Разработчику же передается панель с ручками (symfony приложение с его богатым инструментарием) и модельные классы ( Doctrine ORM, Doctrine ODM и прочая ) для связи БД.
очередная стопицотая проверка полезности генератора рутинного (!) кода
Это исключительно инициатива автора этой статьи.
По поводу цели создания самого продукта, согласен с Вами. При этом остается возможность подменить практически любой класс на свой, тем самым обеспечив нужное в конкретном проекте поведение.
Буквально вчера наткнулся на еще одну тулзу для генерации REST API — Microrest. В этот раз на основе Silex и Doctrine. Почитать о нем можно здесь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
REST API за пару минут с Lionframe