Grails: услуги VS Groovy классы

Документация гласит:

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

У меня есть один контроллер API и несколько классов Groovy в папке src/groovy. Эти классы просто реализуют мою прикладную логику, поэтому действия в контроллере API работают следующим образом:

//index page
def index = {
    render new IndexApi().index(params) as JSON
}

Мне любопытно - есть ли какие-либо причины для переноса моей логики приложений из простых классов Groovy в службы?

Ответы

Ответ 1

Если вам требуется транзакционное поведение, вы должны поместить свою логику в Службы. Иначе вам придется позаботиться об этом самим, что не в духе использования Grails.

Я не являюсь экспертом по grails, я помещаю свои "не транзакционные" классы за уровень сервиса, такие как классы-конструкторы, помощники и другую логику, которая не является транзакционной, но используется с уровня сервиса.

Ответ 2

На самом деле услуги связаны не только с транзакциями. Службы отлично подходят для одноконтактных компонентов с нулевой конфигурацией, и их можно перезагрузить без перезапуска всей среды Grails. И они могут быть обнаружены как артефакты и, следовательно, автоматически открыты с удаленными плагинами.

Ответ 3

Существует три причины:

  • Это делает контроллер меньшим → легче понять и поддерживать

  • Это облегчает вам проверку логики.

  • Вы действительно не хотите управлять своими транзакциями вручную.

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

Например, для тестирования JSP требуется HTTPRequest. Для запроса вам нужна HTTPSession и JSPWriter. Им нужен контекст сеанса. Поэтому, чтобы иметь возможность запускать один тест, вам нужно настроить и инициализировать целую группу классов. И все это интерфейсы, а реализации - частные. Таким образом, вы должны сами реализовать фактические методы (все 300 из них). И вам лучше получить это право или ваши тесты не будут проверять, что вы хотите.