Куда должна идти логика для решения, какой запрос SQL выполнить

Question

У меня есть DAO с методом CommitmentListDAO.getListByOwnerBadge, который возвращает массив элементов обязательств с пропуском супервизора (поле базы данных OWNED_BY)

    String SQL_VIEW_LIST_BY_SUPERVISOR = SELECT_QUERY + 
    " WHERE c.OWNED_BY = ? " +
    " ORDER BY p.PROGRAM_NAME";

Теперь я хочу добавить раскрывающуюся форму в веб-форму, чтобы пользователь мог выбирать между Owned By или Tasked To. Мне нужно добавить предложение WHERE c.TASKED_TO = ? в DAO.

Выполняю ли я логику, по какому полю искать в DAO - скажем, переданный параметр раскрывающегося списка (Никогда объект запроса) и переименовываю метод в getListByBadge(String whichField, String badge), или мой класс CommitmentListForm должен иметь эту логику и затем сделайте соответствующий вызов либо getListByOwnerBadge или getListByTaskeToBadge

Answer 1

Я бы пошел с DAO на это с двумя различными методами, чтобы четко дифференцировать то, что делает вызов.

Цель DAO - скрыть детали реализации SQL.Вы должны всегда рассматривать такой вопрос с точки зрения: «Что если я переключился на другой механизм персистентности, такой как HBase?»Реализация HBase может не хранить это способом, который просто различается по имени поля.DAO должен позволить скрыть эту деталь, таким образом, различные методы.

Только мое мнение, конечно.:)

Answer 2

Я бы определил логику в вашем контроллере и разделил два SQL-запроса на getListByOwnerBadge или getListByTaskeToBadge. Таким образом, вы избегаете использования метода, который «делает все» и может быстро выйти из-под контроля. Кроме того, другие разработчики, которые решат использовать метод «делает все», должны будут проверить внутренности метода, чтобы увидеть, какие допустимые строки могут быть переданы, тогда как явный вызов метода делает очевидным, что метод выполняет.

Answer 3

Я думаю, что второе решение лучше. Держите DAO настолько простым, насколько это возможно. Нет логики, нет флагов. Создайте 2 простых метода и примите решение в форме, какой из них вызывать. Или даже создайте еще один слой между формой и DAO, который решает, какой метод DAO вызвать.

Answer 4

Подводя итог:

From @McStretch - логика для вызова идет в вашем контроллере.

From @rfreak - сами методы запроса идут в DAO

Вот пример:

//Controller
CommitmentListAction {

updateForm(...){ 
  List<CommitmentItem> commitmentItems;
  if (formUsesOwnedBy){
    commitmentItems = CommitmentItemDAO.getListByOwnerBadge(...);
  } else {
    commitmentItems = CommitmentItemDAO.getListByTaskeToBadge(...);
  }
  // Do stuff with commitmentItems.
}
// DAO

getListByOwnerBadge(...){
 String SQL_VIEW_LIST_BY_SUPERVISOR = SELECT_QUERY + 
    " WHERE c.OWNED_BY = ? " +
    " ORDER BY p.PROGRAM_NAME"
  return doQuery(SQL_VIEW_LIST_BY_SUPERVISOR); // Performs the actual query
}

getListByTaskeToBadge(...){
String SQL_VIEW_LIST_BY_TASKED_TO = SELECT_QUERY + 
    " WHERE c.TASKED_TO = ? " +
    " ORDER BY p.PROGRAM_NAME"
  return doQuery(SQL_VIEW_LIST_BY_TASKED_TO); // Performs the actual query
}

Если у вас будет много разных взглядов на CommitmetItems или много разных критериев, рассмотрите возможность передачи этих критериев в DAO.Но делайте это только в тот момент, когда кажется, что существует слишком много методов getListBy [blah], загрязняющих DAO.