Блог

Кто-нибудь мог бы объяснить, возможно ли иметь настраиваемые методы pivate в интерфейсах playfamewok, за исключением:

общедоступный метод статической аннулирования-action-name() {}

Например, если бы у меня был такой метод, как этот:

защищенный статический ввод DoSomeWork() {}

и этот метод будет вызываться в method-action-name() ..

 public static void method-action-name() {
  ...
  int resul = doSomeWork();
  ...
}
  

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

Я имею в виду, нормально ли (с точки зрения playframework) иметь такой метод на стороне контроллера вместо того, чтобы иметь их в классах домена? В Spring Framework для этого, например, мы используем компоненты BP (бизнес-процесс).

Нормально ли иметь такие вспомогательные методы для бизнес-методов в контроллерах playframework?

Добавлено после получения ответа и комментариев: Например, если у меня есть класс SearchController, то для этого класса было бы неплохо иметь такие методы, как preSearch1(), preSearch2(), какой метод search() использовал бы, но если я перенесу эти методы (1,2) в другой класс, тогда это должен быть класс с именем, подобным SearchHelper? в пакете с именем /src/helpers.. не очень приятно, потому что они тоже связаны с поиском. Но, может быть, тогда в /src/bp /SearchBP (bp = бизнес-процесс). И затем в controllers / Search я использую / bp / SearchBP, которые используют некоторый объект модели с методами DAO .save() (SearchBP может использовать методы домена, а класс поиска также может использовать методы домена)

Вопрос здесь: какой пакет ant класса был бы хорош для этих методов? (я только что посмотрел это в примерах — всегда очень простое использование контроллеров, которые используют объект домена, поэтому я спрашиваю)

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

ОТВЕТ НА РЕДАКТИРОВАНИЕ:

Имя пакета «не имеет значения», это не изменит его слишком сильно :). Вы можете поместить их в раздел controllers.support.search, что будет означать, что controllers.support — это пакет со вспомогательными классами, а подпакет search содержит вспомогательные классы и методы, связанные с поиском.

Одна из альтернатив (которая мне нравится больше) — создать для этого уровень обслуживания в пакете «services». Вы, кажется, пришли из Spring background, поэтому для вас это должно быть естественным. Эти службы создаются в контроллере по мере необходимости или, возможно, просто используются с помощью статических методов и выполняют основную бизнес-логику. Таким образом, контроллер обрабатывает только логику «более высокого уровня».

Другой альтернативой является перенос как можно большей части этой логики в модель (избегая анемичной модели предметной области) и использование классов модели из контроллера.

Как и большинство решений при разработке, какое из них лучше, зависит от вашего опыта, возможного влияния / ограничений в кодовой базе, практики в вашем проекте… в любом случае, вы всегда можете провести рефакторинг. Просто выберите тот, к которому вы больше привыкли (похоже, это подход к службам), и кодируйте дальше 🙂

Любое поведение, достаточно сложное, чтобы его можно было описать как «бизнес-логику» (а не «логику представления»), относится к модели, а не к контроллеру. Если ваша модель ничего не делает, кроме сопоставления с набором таблиц базы данных, то она не выполняет свою работу должным образом. Такие вещи, как разрешения и контроль доступа, в частности, должны выполняться моделью.