Лучшие практики, которые следует соблюдать при разработке приложения Grails

При разработке приложения Grails, что вы считаете "лучшими практиками" и почему? Меня не интересует дискуссия о лучших практиках, но одно или несколько утверждений, подкрепленных обоснованием и/или описанием того, когда применяется лучшая практика, а когда нет. Я не верю, что есть один лучший способ разработки приложений Grails, но есть ряд рекомендаций, которые приведут к созданию более удобных приложений с меньшим количеством ошибок, скрывающихся в них.

Мой опыт Grails заключается в том, что он предлагает так много возможностей, что есть соблазн использовать их все в одном приложении, что приводит к некоторому из худшего кода спагетти, который я видел с тех пор, как я отлаживал программу Fortran с операторами GOTO в и из части цикла DO.

Мы все знаем, как Grails создает место для классов, сервисов, просмотров, контроллеров и т.д. Какие функции принадлежат этим местам? Какие эмпирические правила помогают вам поступать правильно? Что такое запахи кода Grails?

ОТВЕТЫ

Ответ 1

  • Понимайте соглашения Grails. Грайлс управляется конвенцией; и соглашения заключаются в том, как Grails может многое сделать для вас. Представления должны быть просто просмотрами. Контроллеры должны быть просто контроллерами. Объекты служб и модели должны содержать всю логику вашего приложения. Это означает, что когда вы нажимаете ссылку или вызываете конечную точку, вы вызываете ее в контроллер. Контроллер вызовет службу (которая может, в свою очередь, вызвать другие службы) и дать краткий ответ. Служба вернет объекты модели или данные в контроллер, который просто сделает соответствующий ответ. Сервисы являются транзакционными, поэтому все, что попадает в базу данных, должно поступать в службу.

  • Test. Контрольная работа. Испытайте еще немного. Проведение тестов - лучший способ гарантировать, что вы сможете добавлять функциональные возможности, не нарушая новых функциональных возможностей, то есть ваш проект может быть удобным.

  • Инъекция зависимостей. Вам нужно поместить ваши компоненты в соответствующую папку grails-app/. Сервисы переходят в папку служб. Контроллеры входят в папку контроллеров. Если у вас есть объект модели Thing, и для этого вам нужен контроллер и служба, то ваш контроллер и служба должны быть названы ThingController и ThingService. Чтобы получить ThingService в своем ThingController, поместите def thingService в свой контроллер, и grails будет автоустанавливать его для вас. Если вы не соблюдаете соглашения об именах и правила для размещения различных компонентов, автоустановка может завершиться неудачей.

  • Понимайте основные технологии, а именно Spring и Hibernate. Вы столкнетесь с проблемами моделирования объектов домена и совместной работы. Grails действительно представляет собой высокопроизводительную инфраструктуру, но если вы не понимаете, как работает Hibernate, вы легко потеряетесь, пытаясь заставить ваше упорство вести себя так, как вы этого хотите.

  • Groovy не является Java. Многие знания Java будут служить вам хорошо. Но Groovy - динамический язык, и у Grails есть свой набор gotchas, который основывается на Groovy. Вы столкнетесь с проблемами во время выполнения в Grails, которые вы во многом избегаете с Java. Тестирование помогает в этом.

Эти вещи кажутся очевидными, но вокруг этих вопросов возникает много вопросов.

Ответ 2

  • Избегайте соблазна положить много логики в веб-слое. Для просмотров, стремиться сделать их такими же простыми, как возможное. Положить столько шаблонов в ваших макетах. Избегайте условных логика, как чума. Отщеплять общий контент в шаблоны и g:render их. Создайте свой собственный taglib для общих элементов пользовательского интерфейса.

  • Аналогично, держите свои контроллеры как можно проще. У неопытных разработчиков, похоже, есть привычка бросать все в контроллер, потому что это кажется наиболее очевидным. Некоторые подсказки: запросы и логика поиска объектов могут идти в объектах домена. Если вы видите withTransaction() и нуждаетесь в транзакционном поведении, это хороший кандидат на услугу. Если у вас сложная привязка данных, разделите ее на объект команды.

  • Для объектов домена воспользуйтесь возможностью переопределения сеттеров и геттеров, чтобы упростить работу с объектами. Создание коротких именованных запросов и объединение их вместе - отличный способ разложить сложную логику запросов. Все, что относится к одному объекту этого типа с несколькими зависимостями, должно идти в классе объектов домена. Однако сохраняйте логику, специфичную для этого объекта. Более сложная бизнес-логика, которая имеет дело с группами объектов, принадлежит сервисам.

  • Если у вас есть сомнения, он может пойти в службу. Услуги должны быть без гражданства. Если вы обнаружите, что вам нужно сохранить состояние, вам, вероятно, понадобится новый объект домена.

Ответ 3

Что я могу придумать...

  • Испытайте столько, сколько сможете, с модульными тестами, а не с интеграционными тестами. Единичные тесты - это способы быстрее запускать/отлаживать и улучшать низкое сцепление. Используйте mockDomain(), mockLogging() и т.д.
  • Используйте grails console для тестирования и изучения вашего кода в дикой природе. Внедрите консоль Groovy в свой веб-интерфейс - это бесценный инструмент для проверки внутренней среды запущенного приложения.
  • Использовать объекты домена для моделирования логики домена. Перемещение логики домена в Службы - похмелье неудобных слоев сохранения.
  • Держите контроллеры краткими. Если логика может быть выражена в терминах определенного класса, переместите туда логику или создайте новый класс. Затем проверьте его.
  • Отдельные слои. Держите доменную логику для классов домена. Храните презентационную логику в контроллерах/представлениях.
  • transactional Служба - это не единственный способ совершить транзакцию. Вызов DomainClass.withTransaction{ ...a couple of lines here... } из контроллера довольно хорош, если они подчиняются # 4.
  • Стремитесь к совершенству - в отличие от Java, это достижимо: D Знайте технологию. Используйте Builders, правильные плагины, команды, метапрограммирование, что бы то ни было, чтобы сделать ваш код короче, читабельнее, groovier.

Ответ 4

  • Разработайте повторно используемые части приложения как плагины Grails. Эти плагины можно тестировать индивидуально и удалить сложность из ваших основных приложений. Рассмотрите возможность публикации плагинов в публичном репозитории плагинов, если вы считаете, что другие могут извлечь выгоду из них.

  • Используйте плагин release (ранее известный как maven-publisher) для развертывания внутренних плагинов в вашем репозитории Maven.

  • Ознакомьтесь с плагинами ресурсов для обработки статических ресурсов. Этот плагин будет частью Grails 1.4 и будет использоваться многими популярными плагинами.

  • Не бойтесь заглядывать в исходный код сторонних плагинов, которые вы используете, или сам Grails (это так меня спасло!). Grails и многие из самых популярных плагинов размещают свой исходный код на GitHub, что делает его очень удобным для просмотра кода, проектов вилок и внесения исправлений.