Зачем использовать сервисный слой? - PullRequest
Новая
       14

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

31 голосов
/ 11 сентября 2010

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

Ответы [ 3 ]

31 голосов
/ 11 сентября 2010

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

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

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

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

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

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

18 голосов
/ 11 сентября 2010

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

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

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

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

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

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

17 голосов
/ 11 сентября 2010

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

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

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

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

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

...