Архитектура Java EE - рекомендуется ли DAO использовать ORM, например JPA 2?

Если я использую ORM, например JPA2 - где у меня есть объекты, которые сопоставлены с моей базой данных, должен ли я использовать DAO? Это кажется намного более накладными расходами.

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

  • Тот, который определяет объекты моего домена (которые в значительной степени отображают мои объекты Entity):

    public class Employee {
    private String firstName;
    private String lastName;
    ...
    // Getters and setters
}

  • Тот, который содержит интерфейсы, которые определяют мои методы DAO

    public interface EmployeeDAO {
    public void addEmployee(Employee employee);
    public Employee getEmployeeById(long id);
    ...
}

  • Тот, который содержит сеанс beans, который реализует мои DAO

    public EmployeeJpaDAO implements EmployeeDAO {
    interface method implementations here
    ....
    private method that transform my Employee entity into my Employee domain object
}

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

Однако преимущества, которые я вижу от наличия DAO:

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

  • Отделяет бизнес-логику от логики доступа к базе данных

Опция, которая не включает реализацию DAO, заключается в том, чтобы просто использовать объекты объекта и EntityManager в уровне обслуживания:

@Stateless
public class EmployeeEjb {
    @PersistenceContext(unitName = "employee")
    private EntityManager manager;

    public Employee getEmployeeById(long id) {
        return manager.createNamedQuery(Employee.GetEmployeeById).getResultList();
    }
    ...
}

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

Спасибо за любые рекомендации и/или предложения! Мне действительно интересно узнать, что некоторые люди придумали в отношении этого.

Ответы

Ответ 1

Если я использую ORM, например JPA2 - где у меня есть объекты, которые сопоставлены с моей базой данных, должен ли я использовать DAO? Это кажется намного более накладными расходами.

Это. И, очевидно, Java EE не поощряет использование шаблона DAO при использовании JPA (JPA уже предоставляет стандартизованную реализацию Магазин доменов, и при его закрытии за DAO не так много значения. Я считаю, что DAO будет анти-DRY в такой ситуации.

Итак, для простых случаев (фактически, в большинстве случаев) я с радостью пропустил DAO, и у меня нет проблем с этим. Для более сложных случаев (например, при использовании хранимых процедур, плоских файлов) я бы использовал его. Другими словами, это зависит от того, как суммировано в Неужели JPA убил DAO?. См. Также следующие вопросы:

Связанные вопросы

(...) Тот, который содержит сеанс beans, который реализует мои DAO

Noooo, вы, разумеется, не хотите реализовывать DAO как сеанс Bean:

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

Итак, если вы действительно хотите пойти по пути DAO и хотите, чтобы EM была введена, либо реализуйте свои DAO как Spring beans (в Java EE 5) или управляемый CDI Bean (в Java EE 6),

У вас может быть реализация DAO в памяти для модульного тестирования вашего уровня обслуживания.

Если вы действительно хотите провести тестирование unit, издевайтесь над DAO/EntityManager, нет никакой разницы. И если вы хотите выполнить интеграционное тестирование, вы можете настроить JPA на использование базы данных в памяти. Поэтому в конце я просто не покупаю этот аргумент.

Отделяет бизнес-логику от логики доступа к базе данных

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

И, по моему опыту, изменение базового решения настойчивости является очень исключительным событием, и я не собираюсь вводить DAO для чего-то, что, скорее всего, не произойдет (YAGNI, KISS).

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

Я не вижу много места и, как сильно намекнул, я не использую DAO, если я не чувствую нужды. И, как я уже сказал, высмеиваем EntityManager, если вы хотите по-настоящему unit test бизнес-логики. Он работает для меня, и я счастлив написать меньше кода.

Дополнительные ресурсы

Ответ 2

Для записи.

Для принципа единой ответственности (SRP) DAO должен иметь, он разделяет модель и логику на уровне персистентности, который может быть легко переносимым.

Если проект использует тестовый модуль, DAO помогает его правильно протестировать (макет, тестирование базы данных и т.д.).

DAO - СЕРВИС, и, как и один, мы можем обернуть наш процесс в класс, который легко поддается обслуживанию.

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

JPA добавляет слой репозитория, но его не НАШ репозиторий. В том же принципе позвольте сказать, что мы инкапсулировали логику, которая получает прибыль от некоторого процесса. Может быть, инкапсуляция - это просто умножение на 0,1, но оно все еще достойно инкапсуляции.

Например, скажем, что у меня есть следующая проблема: по какой-то нечетной причине я могу вставить нового клиента в базу данных?. Где я должен начать тестировать?. a: ClientDao, если существует, если нет, то удачи в другом месте.