Зачем использовать сервисный слой?

Я посмотрел пример на http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639

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

UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}

Похоже, что сервисный уровень — это просто оболочка вокруг DAO. Может ли кто-нибудь рассказать мне о случае, когда все могло запутаться, если сервисный уровень был удален? Я просто не вижу смысла начинать с сервисного слоя.


spring service-layer
person joe martinez    schedule 10.09.2010    source источник

Ответы (3)


arrow_upward
32
arrow_downward

Наличие сервисного слоя в качестве оболочки вокруг DAO является распространенным анти-шаблоном. В приведенном вами примере это, конечно, не очень полезно. Использование сервисного слоя означает, что вы получаете несколько преимуществ:

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

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

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

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

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

person Nathan Hughes    schedule 10.09.2010
comment
В приведенном вами примере это, конечно, не очень полезно, бесполезно сегодня. Это будет завтра, когда вы начнете добавлять больше функций и вам понадобятся логика и правила (которые могут отличаться от одного клиента/установки/и т. д. к другому) - логика, которую не следует размещать на уровне доступа к данным. - person nos; 11.09.2010
comment
@nos: согласен. хотя я не решаюсь советовать людям вставлять что-то только потому, что это может им не понадобиться в будущем, слишком просто, по мере роста приложения, впихивать новые биты в контроллер или дао, потому что это удобно. - person Nathan Hughes; 29.09.2011

arrow_upward
21
arrow_downward

Взгляните на следующую статью:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

Все зависит от того, где вы хотите разместить свою логику — в своих сервисах или объектах домена.

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

Однако в большинстве случаев вам нужна простая архитектура, поэтому пропустите уровень службы и посмотрите на подход модели предметной области. Проект, управляемый доменом, Эрик Эванс и статья InfoQ здесь раскрывают это:

http://www.infoq.com/articles/ddd-in-practice

person Jon    schedule 10.09.2010

arrow_upward
20
arrow_downward

Использование сервисного слоя является хорошо принятым шаблоном проектирования в сообществе Java. Да, вы можете сразу использовать реализацию dao, но что, если вы хотите применить некоторые бизнес-правила.

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

Как правило, хорошо содержать слой дао в чистоте и порядке. Я предлагаю вам прочитать статью "Не повторяйте DAO"< /а>. Если вы будете следовать принципам, изложенным в этой статье, вы не будете писать никаких реализаций для своих даосов.

Кроме того, обратите внимание, что целью этого сообщения в блоге было помочь новичкам в Spring. Spring настолько мощен, что вы можете изменить его в соответствии со своими потребностями с помощью мощных концепций, таких как aop и т. д.

С уважением, Джеймс

person James Selvakumar    schedule 11.09.2010
comment
perform some checks before allowing a user to login into the system вы можете сделать это, внедрив BLL - person Yousha Aleayoub; 19.12.2019