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

Я посмотрел пример на 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. Может ли кто-нибудь дать мне случай, когда что-то может стать беспорядочным, если слой обслуживания был удален? Я просто не вижу смысла в том, чтобы начать использовать сервисный уровень.

Ответы

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

В целом хорошо держать ваш слой dao чистым и худым. Предлагаю вам прочитать статью "Dont repeat the DAO" . Если вы будете следовать принципам в этой статье, вы не будете писать какую-либо реализацию для своих даос.

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

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

Ответ 3

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

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

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

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

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

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