Текущая реализация работает только с жестко заданными областями.В общем случае наличие динамических областей ничем не отличается от наличия дополнительного параметра в методе 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).
Как вы можете видеть, мало что даст вам области, поскольку внутренняя реализация модели может или не может использовать области, вы получите те же результаты.Этот шаблон кодирования намного лучше, потому что:
- У вас есть статические методы на моделях, которые вы можете проверить
- У вас есть статические методы, которые могут иметь защитные операторы
if (department = null) throw new IllegalArgumentException("blah...")
- У вас есть статические методы в моделях с хорошими семантическими именами
- Реализация и доступ к вашей таблице заключены в один класс, а не стерты снаружи (контроллеры).
- Легко сделать рефакторинг в будущем.
Однако, если вы используете этот подход, значение областей будет близко к нулю.
Само собой разумеется, я не использую области в своей работе.