ActiveJDBC: использовать область с динамическими параметрами - PullRequest
Новая
       33

ActiveJDBC: использовать область с динамическими параметрами

0 голосов
/ 24 сентября 2018

Фактические примеры области действия обеспечивают использование жестко закодированных параметров, передаваемых в запрос: 

public class Employee extends Model {
    static {
        addScope("byDepartment", "department = 'marketing'");
    }
}

Возможно ли сделать этот параметр динамическим и всю область следующим образом:

public class Employee extends Model {
    static {
        addScope("byDepartment", "department = '?'");
    }
}

Пример использования: 

Employee.scope("byDepartment").where(....) <-- how to pass in a department value ?

Спасибо.

Ответы [ 2 ]

0 голосов
/ 23 октября 2018

Я не вижу ничего плохого в том, чтобы сделать параметр динамическим, как в вашей модели Employee: 

public class Employee extends Model {
    static {
        addScope("byDepartment", "department = '?'");
    }
}

проблема на самом деле в 

Employee.scope("byDepartment").where(....)

рядом с scopeName, scope()не предоставляет никакого способа для дополнительных параметров для scopeValue (s).

Вместо этого вы можете вызвать Employee.where(subquery, params)

, где subquery будет вашим scopeQuery, к которому вы можете получить доступ с помощью ModelDelegate.getScopes().get(scopeName)и params будет вашим значением.

0 голосов
/ 24 сентября 2018

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

Этот вопрос требует философской дискуссии.Обычно вы используете модель в качестве собственного сервиса.Другими словами, использование подобной модели извне модели не является предпочтительным способом: 

List<Employee> employees = Employee.scope("byDepartment").where("start_date > ?", startDate);

Лучше всего свернуть весь доступ к таблице EMPLOYEES в класс Employee следующим образом:

public class Employee extends Model{
   public static List<Employee> getStartedByDepartment(Date started, String department){
          return Employee.scope(department).where("start_date > ?", started);
  } 
}

Мы кодируем все проекты JavaLite с этим шаблоном и не разрешаем ActiveJDBC API отбирать внешние модели (по большей части, lol).

Как вы можете видеть, мало что даст вам области, поскольку внутренняя реализация модели может или не может использовать области, вы получите те же результаты.Этот шаблон кодирования намного лучше, потому что:

  1. У вас есть статические методы на моделях, которые вы можете проверить
  2. У вас есть статические методы, которые могут иметь защитные операторы if (department = null) throw new IllegalArgumentException("blah...")
  3. У вас есть статические методы в моделях с хорошими семантическими именами
  4. Реализация и доступ к вашей таблице заключены в один класс, а не стерты снаружи (контроллеры).
  5. Легко сделать рефакторинг в будущем.

Однако, если вы используете этот подход, значение областей будет близко к нулю.

Само собой разумеется, я не использую области в своей работе.

...