ДАО и Сервис?

Question

Я всегда сталкиваюсь с проблемой, когда я не могу думать о сервисном объекте, инкапсулирующем многие методы DAO.

Я имею в виду, что для моего сервлета иногда достаточно использовать один метод DAO, например addUser (User params).

Что лучше сделать - инкапсулировать методы DAO в объект службы и использовать ВСЕГДА только объекты службы, даже если это буквально означает один метод службы, вызывающий один метод dao или смешивающий их использование вместе (некоторые методы из объектов службы и некоторые из дао в контексте сервлета) - имеется в виду, что у меня есть автоданные DAO и объекты службы внутри контроллера?

Это смешивает логику, если я начинаю использовать DAO и объект Service в одном месте?

Answer 1

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

Однако, если ваш DAO является "фиктивным" и просто вызывает метод EntityManager, вы, вероятно, можете использовать это непосредственно в своих сервисных объектах. Идея состоит в том, чтобы иметь классы с отдельными обязанностями , которые легко расширять и тестировать. Вы не должны создавать слои ради этого.

Вероятно, я бы не использовал DAO напрямую с ваших контроллеров, если вы хотите сохранить слой многократного использования. Я бы предпочел использовать EntityManager (или любую другую стратегию персистентности, которую вы используете) на уровне сервисов, если DAO не имеет смысла.

Answer 2

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

Одна из них - это старое доброе "Вам оно не понадобится".Не реализовывайте что-либо, пока оно вам не понадобится.Просто потому, что вы предвидите какую-то причину иметь дополнительный уровень косвенности для выполнения некоторой дополнительной логики, она не уверена, что она вам понадобится.И когда вы в конечном итоге нуждаетесь в этом, вы, вероятно, обнаружите, что ваши ожидания не совсем соответствовали тому, во что вы верили ранее.И вы получаете дополнительную плату, потому что теперь вам нужно провести модульное тестирование двух классов вместо одного, и нередко вам нужно добавлять методы в двух местах вместо одного.

Во-вторых, какого чертаэто сервис в любом случае?Когда я моделирую свой домен, я стараюсь мыслить объектно-ориентированными терминами.Есть пользователи, поэтому класс User имеет смысл.Есть новости, поэтому класс NewsItem имеет смысл.Но я даже не знаю, что должен делать UserService.Содержать «бизнес-логику» для пользователей?Нет, для этого есть класс User.

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

Answer 3

Зависит.Причины разделения DAO и сервисного уровня часто:

• технические ограничения (см. Транзакции AOP в другом ответе)
• архитектурные ограничения (преобразование DTO <=> @Entities между сервисным уровнеми DAO)
• исторический (это было сделано в течение X лет)
• эстетический (доступ к слою вида только к одному слою)

Используя Java EE 6 (JBoss AS 7), у меня нет такой нагрузки:

• Нет AOP - @Stateless и @Transactional заботятся о транзакциях.
• Нет DTO - Iиспользуйте @Entities от JPA до слоя представления.
• Не заботьтесь об истории.
• И я предпочитаю простоту / меньше кода эстетике.

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

Мое эмпирическое правило, должен ли метод переходить в компонент службы:

1. Если он использует несколько DAO (очевидно)
2. Если он выполняет несколько вызовов менеджера сущностей
3. Если реализация может измениться, например, поиск в JPQL или HibernateПоиск против ElasticSearch.

Answer 4

Лично я обычно инкапсулирую вызовы DAO в сервисах.

Это позволяет мне сделать все сервисы транзакционными, используя AOP / etc. и использовать нетранзакционные методы DAO в этих сервисах.

Для тривиальных услуг это дополнительный «уровень», но IMO, который служит цели (и генерация кода того или иного рода может использоваться для его генерации в любом случае). Также редко у меня есть только функциональность DAO, заключенная в службу, хотя.