бизнес-методы в игровых приставках - PullRequest
Новая
       10

бизнес-методы в игровых приставках

5 голосов
/ 09 мая 2011

Может кто-нибудь объяснить, можно ли использовать poteate, pivate методы в контроллерах playfamewok, кроме:

public static void method-action-name () {}

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

защищенное статическое int 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 , которые используют некоторый объект Model с методами .save () DAO (SearchBP может использовать методы Domain, а класс Search может использовать методы Domain как хорошо)

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

Ответы [ 2 ]

4 голосов
/ 09 мая 2011

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

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

Название пакета "не имеет значения", не сильно изменит его :).Вы можете поместить их в controllers.support.search, что означает, что controllers.support - это пакет с вспомогательными классами, а поиск в подпакете содержит вспомогательные классы и методы, связанные с поиском.создать сервисный слой для этого в пакете «услуги».Вы, кажется, пришли из источника Spring, так что это должно прийти к вам естественным образом.Эти службы создаются в контроллере по мере необходимости или, возможно, просто используются статическими методами и выполняют основную бизнес-логику.Таким образом, контроллер работает только с логикой «более высокого уровня».

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

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

1 голос
/ 10 мая 2011

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

...