Использование DAO в качестве команды

Question

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

Мы реализуем поставщик веб-сервисов Java, который работает с данными в реляционной базе данных.Предлагаемые классы:

1. IDAO - интерфейс с методом execute ()
2. GetCustomerDAO и UpdateCustomerDAO реализуют IDAO
3. DAOFactory - список DAO для чтения конфигурационного файла, которыйимеет сопоставление DAO, которые будут вызываться для конкретной службы.
4. ServiceImpl - содержит методы getCustomer, updateCustomer.Служба использует DAOFactory для получения списка объектов DAO, затем выполняет итерацию по списку и вызывает метод DAO.execute.

Я думаю, это больше похоже на то, что мы преобразовали DAO в Command.Однако мне не очень нравится этот подход по ряду причин: - В ServiceImpl: вы не можете влиять на поток вызываемых DAO.Например, после выполнения 1-го DAO, если я не хочу выполнять 2-й DAO, но выполняю 3-й DAO, это трудно реализовать.- кроме того, не уверен, сможем ли мы концептуально использовать DAO.поскольку объект Command может иметь бизнес-логику, однако DAO должны иметь дело только с аспектами чтения и записи данных в базу данных.

Пожалуйста, дайте мне знать ваше мнение, выглядит ли дизайн соответствующим.спасибо

Answer 1

Я не вижу преимущества использования шаблона проектирования Command в этом случае.
1. Идея DAO - предоставить интерфейс, который абстрагирует механизм персистентности. Этот интерфейс традиционно определяет методы CRUD. Каждый конкретный класс DAO, как правило, реализует интерфейс DAO для определенного механизма персистентности. Например, у вас может быть одна реализация, которая хранит данные в реляционной базе данных, и другая, которая хранит данные в файле XML. Обе эти реализации могут быть взаимозаменяемыми, поскольку они реализуют один и тот же интерфейс.
2. Функциональные возможности службы могут быть разделены на отдельный уровень обслуживания. Обычно этот уровень зависит от уровня DAO (для сохранения). Интерфейс службы может быть похож на фасад, который предоставляет потенциальным клиентам бизнес-логику, реализованную в приложении (обычно логику на бизнес-уровне). Пример:
Пользовательский интерфейс DAO:

public interface UserDao {
    void save(User user);
    void delete(User user);
    void update(User user);
    User findByUsername(String username);
    List findAll();
    ...
}

Интерфейс обслуживания пользователя:

public interface UserService {
   void createUser(String username, String password);
   boolean loginUser(String username, String password);
   boolean isUsernameUnique(String username);
   ....
}

Реализация услуги:

public class UserServiceImpl implements UserService {

  private UserDao userDao;

  public UserServiceImpl(UserDao userDao){
    this.userDao = userDao;
  }
  ...
}