2010-03-22 11 views
5

que era reading this page y me encontré con la siguiente declaración:Coloque la lógica de negocio en Java Beans?

MVC en Java Server Pages

Ahora que tenemos un cómodo architucture para separar la vista, cómo podemos aprovechar eso? Java Server Páginas (JSP) se vuelve más interesante porque el contenido HTML puede ser separado de los objetos comerciales de Java . JSP también puede hacer uso de Java Beans. La lógica de negocios podría ubicarse dentro de Java Beans. Si el diseño está diseñado correctamente, un diseñador web podría trabajar con HTML en el sitio JSP sin interferir con el desarrollador de Java.

Curiosamente en mi libro de texto me sacó la siguiente cita:

En la arquitectura MVC ... la solicitud original siempre es manejado por un servlet. El servlet invoca la lógica de negocios y el código de acceso a datos y crea beans para representar los resultados (ese es el modelo). Luego, el servlet decide qué página del servidor Java es adecuada para presentar esos resultados particulares y reenvía allí la solicitud (el JSP es la vista). El servlet decide qué negocio se aplica al código lógico y cuál JSP debe presentar los resultados (el servlet es el controlador).

Las dos afirmaciones parecen ligeramente contradictorias. ¿Cuál es la mejor manera de usar frijoles: deberíamos colocar la lógica comercial en ellos o deberíamos solo colocar resultados en ellos? ¿Hay formas en que los frijoles son inadecuados para representar un modelo?

Respuesta

4

También es bastante común que la lógica de negocios se coloque en clases con un sufijo de Administrador. Aunque algunas personas ponen lógica empresarial en el bean de objetos de datos, me parece mejor que los métodos en el objeto de datos solo hagan funciones simples que no dependan de ninguna dependencia externa. Todo el resto de la lógica de negocio que coloco en un bean Manager que es capaz de usar múltiples javabeans de objetos de datos y otras dependencias externas para seguir la lógica comercial. Entonces, por ejemplo, un AccountBean contendría los campos de la cuenta y tal vez algunos métodos simples que usan esos campos para calcular y devolver un valor, o formatear un campo. Toda la lógica comercial estaría en un Manager, posiblemente un AccountManagerBean.

+0

¿Utiliza su JSP el bean Manager o solo usa el bean modelo? – Kiril

+0

Es de esperar que su punto de vista tenga algo detrás del JSP, en Struts it's y Action Class, en algunos lugares es una clase servlet, otros frameworks usan otras cosas. En esa clase de Java puede usar el Administrador para buscar, actualizar, agregar, eliminar pasar su bean de datos. En el JSP, es mejor mantener la mayor cantidad de Java fuera de él, así que solo usaría Java View Data View allí y mantendría al Administrador fuera. –

3

La segunda afirmación básicamente se refiere a dos JavaBeans: uno para la lógica comercial y otro para el modelo. Por lo tanto, sí, la lógica de negocios aún se puede colocar en JavaBeans. El javabean para la lógica de negocios puede encapsular el javabean para el modelo como su propiedad.

public class User { 
    private Long id; 
    private String name; 
    // ... 
} 

public class UserManager { 
    private User user; 
    // ... 

    public void login() { 
     // ... 
    } 

    public void logout() { 
     // ... 
    } 
} 
+0

¿Conoce alguna situación en la que el frijol no sea adecuado para presentar un modelo? No he encontrado suficientes situaciones para tener un buen ejemplo, pero ¿cuál sería un ejemplo de un modelo inadecuado para los frijoles? – Kiril

+0

Además: ¿se utilizan beans comerciales en el JSP al igual que se usa un bean modelo? – Kiril

+0

No veo situaciones donde un frijol puede no ser adecuado para representar un modelo. Y sí, puedes usarlo en JSP de la misma manera; para acceder a las propiedades.Las acciones deben ser invocadas por el controlador dependiendo de la solicitud. – BalusC

Cuestiones relacionadas