DAO на сущность или в случае использования

Question

У меня есть ситуация, когда я думаю, я должен создать DAO для каждого объекта или для использования.

У меня есть таблица «пользователь», которая хранит регистрационную информацию пользователей.

create table user (user_id varchar(50) not null primary key, password varchar(50)) 

У меня есть таблица «user_login_history», который хранит историю, сколько раз логин пользователя в системе.

create table user_login_history (user_login_history_id int not null identity(1,1) primary key, user_id varchar(50) not null foreign key references user(user_id), login_date datetime not null) 

Это случай использования: Для пользователя для входа в систему, он/она должна пройти эти 2 проверки:

1. пользователя Id и пароль должны совпадать в таблице
пользователя
2. 30 дней не прошло после последнего входа пользователя в систему.

Так что я Субъект Пользователь

public class User { 
    private String userId; 
    private String password; 
    public String getUserId() { return this.userId; } 
    public void setUserId(String userId) { this.userId = userId; } 
    public String getPassword() { return this.password; } 
    public void setPassword(String password) { this.password = password; } 
} 

И я Субъект UserLoginHistory

public class UserLoginHistory { 
    private int userLoginHistoryId; 
    private User user; 
    private java.util.Date loginDate; 
    public int getUserLoginHistoryId() { return this.userLoginHistoryId; } 
    public void setUserLoginHistoryId(int userLoginHistoryId) { this.userLoginHistoryId = userLoginHistoryId; } 
    public User getUser() { return this.user; } 
    public void setUser(User user) { this.user = user; } 
    public java.util.Date getLoginDate() { return this.loginDate; } 
    public void setLoginDate(java.util.Date loginDate) { this.loginDate = loginDate; } 
} 

Так что я думаю, что у меня есть 2 варианта:

1) Создать DAO с помощью лица, которое означает 2 объектов DAO:

UserDAO для пользователя лица, которое будет основываться на «пользователя» таблицы и

UserLoginHistoryDAO для UserLoginHistory лица, которое будет основываться на «user_login_history» таблица

public interface UserDAO { 
    public User getUser(String userId, String password); 
} 

public interface UserLoginHistoryDAO { 
    public UserLoginHistory getLastUserLoginHistory(String userId); 
} 

2) создание DAO путем использования случае это означает, 1 DAO:

LoginDAO, у которого будет весь sql, необходимый для этого варианта использования.

public interface LoginDAO { 
    public User getUser(String userId, String password); 
    public UserLoginHistory getLastUserLoginHistory(String userId); 
} 

какой выбор предпочтительнее и почему?

Если у меня есть выбор 1, что делать, если мне нужен запрос, который использует таблицы «user» и «user_login_history» и возвращает столбцы из обеих таблиц; в том случае, когда DAO будут проходить эти типы запросов? UserDAO или UserLoginHistoryDAO или новый DAO для композитных?

Благодаря

Answer 1

Я хотел бы предложить, что есть третий вариант, при котором вы сохраняете как объекты DAO (с отображением на один-к-одному между аксессором и БД таблицей), а затем наложить третий аксессор, который облегчает более легкую работу API более низкого уровня.Этот третий аксессор требует двух других аксессуаров для строительства, поэтому;

public LoginAccess(final UserDAO userAccess, 
        final UserLoginHistoryDAO userHistoryAccess) 

Преимущества этого подхода заключаются в следующем:

1. Вы можете сохранить объем ваших аксессоров как можно меньше - сделать реализации истории DAO пользователя/пользователя требуют public аксессоров если предполагаемое использование только через LoginAccess?
2. Вы можете создать более блок-как тестовые примеры для этой настройки. Все тесты уровня db больше на стороне интеграционных тестов, но набор тестов для табличного запроса хорош, и также полезно иметь набор тестов для каждой функции (не беспокоясь о используемом SQL). И наоборот, набор тестов, которые проверяют функцию и SQL за один шаг, по своей природе более хрупкие.
3. Этот третий подход более тесно Твердые принципы

Я думаю 1 & 2 являются ключевыми следующим образом - как правило, я считаю, что если есть способ, я могу написать более эффективные модульные тесты и уменьшить общественно-облицовочный API затем Я приму этот подход. Если позже мой подход окажется неадекватным (вероятно!), У меня есть надежный набор тестов, на котором я могу активно реорганизовать.

Answer 2

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

Answer 3

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

В этом случае у вас может быть LoginService, где вы бы назвали UserDAO и UserLoginHistortDAO для реализации требуемой функциональности.

Я думаю, что только исключение из вышеприведенного подхода - это производительность, когда мы отдаем приоритет производительности по сравнению с другими нефункциональными требованиями. В этом случае нам, возможно, придется разрабатывать наши DAO на основе Use Case, а не на сущности/таблице.