Необходимо ли для уровня сервиса в проекте Java EE разговаривать с сущностями через уровень DAO?

Я читаю Эту статью на EJB 3.0, где автор описывает архитектуру, в которой уровень сервиса разговаривает с сущностями через DAO, реализованный как безгосударственный сеансовый Боб.

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

Является ли это единственной причиной, или есть ли и другие причины ?

3 5
ejb

3 ответа:

DAO - это абстракция о том, как получить доступ к базе данных с помощью объектов. В первоначальной практике DAO сначала появляется интерфейс, определяющий операции, которые вы ожидаете от своей базы данных: 

interface ModelDao {
  Model load(Long id);
  Long save(Model object);
}

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

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

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

И последнее, но не менее важное, хотя всегда лучше придерживаться первоначальной практики, это зависит от размера и намерений вашего продукта/проекта принять подход.
2

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

Уровень сервиса общается с сущностями через DAO

Это предложение несколько двусмысленно. С EJB 3.0, бизнес-объекты POJO. Бизнес-уровень может использовать их, а доступ к данным и слой тоже. Бизнес-слой `разговаривает " непосредственно с хозяйствующими субъектами. Но он также обращается к уровню доступа к данным. Уровень доступа к данным отвечает в основном за загрузку и сохранение сущностей.

Демарация транзакций-это еще одна проблема, с которой нужно иметь дело. С EJB 3.0 уровень бизнеса демаратизует транзакции независимо от выбранного startegy персистентности. Уровень доступа к данным и бизнес-объекты должны обеспечивать выполнение транзакций бизнес-уровня.

Мы можем легко протестировать уровень сервиса, насмехаясь над DAO.

Да. Бизнес-уровень можно протестировать, используя макет уровня доступа к данным. Уровень доступа к данным можно протестировать и без бизнес-уровня. Опять же, это легко, потому что бизнес-объекты являются POJO, которые могут быть использованы обоими слоями. Информация, необходимая для уровня доступа к данным, предоставляется с помощью аннотаций, которые не имеют отношения к бизнес-уровню, но не накладывают ограничений на моделирование. хозяйствующих субъектов с точки зрения бизнеса.

4

Одна мысль, которая приходит мне в голову-легкость проверки

Нет, это не просто для удобства тестирования слоя DAO. Цель Дао в данном случае состоит в том, чтобы отделить беспокойство.

@ewernli и @nobeh объяснили назначение слоя DAO и т. д. Добавлю, это один из подходов к решению проблемы. Скорее в мире Java этот подход использования явного слоя DAO существует уже довольно давно. Существуют альтернативные подходы, которые можно реализовать. Например, возьмем случай ActiveRecord в Ruby/RoR world.

Почему уровень сервиса не может напрямую общаться с сущностями?

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

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

1