métodos de negocio en playframework contolles

Question

Podrían explicar a alguien es posible tener potected, métodos pivate en contolles de playfamewok excepto:

método nombre-acción-public void() {}

Para ejemplo si tendría método como este:

protegida static int doSomeWork() {}

y este método se invoca en método nombre-acción-() ..

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

no quiero tener tiempo de acción y método, así que me gustaría que dividir a los más pequeños, y luego reutilizarlo en otros métodos de acción.

Quiero decir, ¿está bien (desde el punto de vista de playframework) tener dicho método en el lado del controlador en lugar de tenerlos en las clases de dominio? En Spring Framework, usamos frijoles BP (proceso de negocio) para eso, por ejemplo.

¿Está bien tener estos métodos de ayuda para los métodos de negocio en los controladores de marco de juego?

Agregado después de tener respuesta & comentarios: Por ejemplo si tengo clase SearchController entonces para esa clase sería bueno tener métodos como preSearch1(), preSearch2() lo de búsqueda() Me gustaría usar el método, pero si muevo estos métodos (1,2) a otra clase, entonces debería ser una clase con el nombre SearchHelper, entonces? en el paquete llamado /src/helpers .. no muy agradable porque se relacionan con la búsqueda también. Pero tal vez entonces en /src/bp/SearchBP (bp = business-process). Y luego, en controladores/Buscar yo uso /pb/SearchBP que utilizan un objeto Modelo con .save (métodos DAO) (SearchBP se pueden utilizar métodos de dominio y de Búsqueda clase puede utilizar métodos de dominio), así

La pregunta aquí: ¿qué clase de paquete de hormigas sería bueno para esos métodos? (Acabo de verlo en ejemplos - siempre hay un uso muy simple de los controladores que usan el objeto de dominio por el que pregunto)

Answer 1

sí, puede. Los controladores son clases normales, puedes agregar lo que quieras. No se recomienda que los atestare con métodos de ayuda, yo personalmente los movería a otra clase, pero puedes hacer lo que dices.

RESPUESTA PARA EDITAR:

El nombre del paquete es "irrelevante", no va a cambiar demasiado :). Puede ponerlos bajo controllers.support.search, lo que significa que los controladores.support es un paquete con clases de ayuda y la búsqueda de subpaquetes contiene clases de ayuda y métodos relacionados con la búsqueda.

Una alternativa (que me gusta más) es crear una capa de servicio para eso, en un paquete de "servicios".Pareces venir de un fondo de primavera, por lo que debería ser algo natural para ti. Estos servicios se crean instancias en el controlador según sea necesario, o tal vez solo se utilizan a través de métodos estáticos, y hacen la lógica de negocios principal. De esta forma, el controlador solo aborda la lógica de "nivel superior".

Otra alternativa es trasladar la mayor cantidad posible de esa lógica al Modelo (evite el Anemic Domain Model) y utilizar las clases de Modelo desde el controlador.

Como la mayoría de las decisiones en el desarrollo, cuál es mejor depende de su experiencia, posibles impactos/limitaciones en la base de código, prácticas en su proyecto ... de todos modos, siempre puede refactorizar. Simplemente elija el que esté más acostumbrado (parece ser el enfoque de Servicios) y codifique :)

Answer 2

Cualquier comportamiento que sea lo suficientemente complicado para describirse como "lógica de negocios" (en lugar de "lógica de presentación") pertenece a el modelo, no el controlador. Si su modelo no hace más que asignar a/desde un conjunto de tablas de base de datos, entonces no está haciendo su trabajo correctamente. Cosas como los permisos y el control de acceso, en particular, deberían ser aplicados por el modelo.