Какая логика должна идти в классе домена и что нужно делать в сервисе в Grails?

Question

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

Исходя из фона в основном разработки Ruby on Rails, я чувствую себя очень склонным вкладывать почти все в класс домена, к которому он относится. Но, с приложением, большим, чем тот, который я переношу, некоторые классы будут длинными тысячами и тысячами строк.

Как вы решаете, что нужно делать в домене, и что нужно делать в службе? Существуют ли какие-либо установленные передовые методы? Я немного осмотрелся, но большинство людей, похоже, признают эту проблему.

Answer 1

В общем, основной ориентир я следую за это:

Если кусок логики относится к более чем одному классу домена, поместите его в сервис, в противном случае он переходит в класс домена.

Без получения более подробной информации о какой логике вы имеете дело с, это трудно идти гораздо глубже, чем это, но вот еще несколько общих мыслей:

1. Для вещей, которые касаются просмотра презентации, те, которые входят в теги libs (или, возможно, услуги)
2. Для получения информации о том, что отправить на просмотр и с какого вида отправить его, что входит в контроллеры (или, возможно, услуги)
3. Для вещей, которые разговаривать с внешними объектами (то есть с файловой системой, очередями и т. д.), те идут в услугах

В целом, я склонен ошибаться на стороне слишком большого количества услуг, кроме того, что вещи слишком слиты вместе. В конце концов, все дело в том, что имеет смысл в вам и как вы думаете о коде и как его поддерживать.

Единственное, что я хотел бы обратить внимание, однако, заключается в том, что, вероятно, существует высокий уровень дублирования кода в том, что вы переносите. Когда Grails строится на Groovy и имеет доступ к более мощным методам программирования, таким как Closures, вполне вероятно, что вы можете очистить и упростить много вашего кода.

Answer 2

С точки зрения Java EE: в классах классов вообще нет логики. Держите свои классы домена как можно более легкими и короткими. Ваша модель домена является ядром вашего приложения и должна быть легкодоступна.

• Grails разработан для инъекций зависимости. Вся логика, которая находится в классе домена, трудно проверить, и слишком легко рефакторировать.
• Вы не можете обмениваться реализациями, как с сервисами (DI).
• Вы не можете легко проверить код своего домена.
• Вы не можете масштабировать систему, так как ваши реализации не могут быть объединены как службы.

Моя рекомендация: Держите каждую логику в сервисах.Службы легко проверяются, легко повторяются, просты в обслуживании, легко перестраиваются.

Конкретно для грааля: если вы измените свой класс домена, бит памяти в памяти будет убит, поэтому вы потеряете тестовые данные, что предотвратит быстрое создание прототипов.

Answer 3

Я лично считаю, что это не только решение между сервисом и классом домена, но и плагины или код.

Подумайте о динамических искателях, таких как Book.findAllByName(). Замечательно, что Grails вводит их в классы домена. В противном случае они должны быть скопированы в каждый класс домена или они будут вызваны через службу (dynamicFinderService.findAllByName('Book') -argh).

Так что в моих проектах, у меня есть довольно много вещей, которые я буду двигаться в плагин и инъекционные в доменных классов ...

Answer 4

посмотрите на Grails Best Practices

Я думаю, что это хорошо статья, объясняющая передовые методы