Создание уровня обслуживания и уровня DAO (интерфейс + реализация) или только реализация

Question

Меня смущает структура создания слоя service и слоя DAO : в некоторых примерах я вижу, как некоторые люди создают interface + реализация как для службы, так и для DAO, и в других примерах я вижу людей, создающих реализацию только , особенно когда DAO расширяет класс AbstractDao , который содержит универсальные методы для этих DAO.поэтому я не понимаю, к чему стремиться, зачем искать это или другое решение, и какова лучшая практика (обычно используемая), пожалуйста, сообщите.

Answer 1

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

DAO - это более внутренняя часть, но я всегда стараюсь использовать интерфейсы для них, чтобы упростить тестирование.

Answer 2

Я предпочитаю реализации интерфейса + по следующим причинам:

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

Реализованные подклассы используются для создания бизнеса /логика приложения, которая соответствует контракту интерфейса.

Answer 3

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

Answer 4

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

Кроме того, у меня нет слоя DAO, так как я использую hibernate, и это кажется излишним.Многие мои рассуждения основаны на этом блоге, красноречиво написано Bozho .

1006 * Я думаю, что это довольно спорно (независимо от того, чтобы иметь DAO и спящий режим), однакоЯ вполне доволен своим решением: я передаю толстые доменные объекты, а затем просто вызываю сеанс гибернации.Каждый метод на слое dao будет буквально одной строкой (session.persist (mObject) или подобным).

Один аргумент, который я услышал против этого, был о том, что слой дао облегчит изменение / удаление orm на более позднем этапе.Я не уверен, что время, потраченное на кодирование слоя дао, в первую очередь добавленное ко времени кодирования изменения, будет меньше, чем на кодирование изменения без слоя дао.Мне никогда не приходилось менять технологию ORM там, где я работал, поэтому это небольшой риск.

Answer 5

Прочтите мой пост о "fastcode" плагине eclipse-spring, который генерирует сервисный слой из ваших DAO.Работает как шарм. создание сервисного / дао слоя для GWT / Spring / Hibernate / PostgreSQL

Answer 6

Другим аргументом для интерфейса + модель реализации является то, что прокси для интерфейсов поддерживаются самой Java, в то время как для создания прокси для реализаций требуется использование библиотеки, такой как cglib .И эти прокси необходимы для поддержки транзакций и т. Д.

Answer 7

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

Подумайте о сценарии, в котором вы используете Hibernate для персистентности (уровень DAO), и вам нужно переключиться на JPA, iBatis или любой другой ORM по этому вопросу.

Если вы используете интерфейсы, вы можете просто написать реализацию, специфичную для JPA, и «подключить» ее вместо Hibernate.Сервисный код остается прежним.