несколько методов на службе Grails

Я создал одну службу в своем приложении Grails. в этом сервисе 25 методов. Некоторые методы предназначены для извлечения данных и передачи их контроллеру, некоторые методы предназначены для применения бизнес-логики, а другие — для операций CRUD с данными базы данных.

Стоит ли писать несколько методов с разным поведением для обслуживания? и Должен ли я сделать услугу транзакционной?

и что такое использование метода по умолчанию

def serviceMethod() {

    }

?

этот метод создается, когда я создаю новую службу...


grails spring-transactions grails-orm transactionscope grails-2.0
person sanghavi7    schedule 13.06.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Стоит ли писать несколько методов с разным поведением для обслуживания?

Несколько методов в службе — это прекрасно, и просто имеет смысл, если методы в службе связаны с контекстом.

Возьмем, к примеру, службу под названием springSecurityService. Вы ожидаете, что содержащиеся в нем методы будут связаны с операциями безопасности spring. Вы не ожидаете найти там метод sendMail.

Должен ли я сделать услугу транзакционной?

Вы должны сделать службы транзакционными, если в этой службе вы выполняете операции с базой данных (в основном пишет!). Когда ваша служба является транзакционной, у вас есть возможность откатить операцию базы данных в случае сбоя.

какая польза от метода по умолчанию

Метод по умолчанию — это просто заполнитель. Не стесняйтесь редактировать или удалять его :D

person gotomanners    schedule 13.06.2012
comment
спасибо @gotomanners, и хочу спросить: это хорошая идея - создать общий сервис для сохранения всех объектов? означает вызов одного метода, который определен в сервисе для хранения моего объекта? - person sanghavi7; 13.06.2012

arrow_upward
2
arrow_downward

Службы в Grails по умолчанию являются транзакционными — http://grails.org/doc/latest/guide/services.html#declarativeTransactions

serviceMethod создается сценарием CreateService. Это просто пример, поэтому вы можете удалить его, если хотите.

Вы можете поместить всю свою бизнес-логику в сервисы. Это удобно, но учтите, что это скорее антишаблон под названием Модель анемичной доменной области.

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

person aldrin    schedule 13.06.2012
comment
Спасибо за ответ, чувак, но я не совсем понял, что ты хочешь сказать? - person sanghavi7; 13.06.2012
comment
я пытался объяснить, куда должна идти ваша бизнес-логика, но, очевидно, я плохо справился :) - person aldrin; 13.06.2012