Tenga en cuenta que a pesar de que [icefaces] etiquetado, esta respuesta se aplica en JSF, en general, no en IceFaces.
En el patrón MVC, lo que es componente del modelo en el JSF? ¿Es el Bean Administrado?
Correcto. La vista es la página JSP/Facelets. El controlador es el FacesServlet. Para obtener más detalles sobre cómo funciona "debajo de las sábanas", ver también this answer.
¿Es buena idea escribir la lógica comercial en los métodos de acción? He visto cientos de líneas escritas en métodos de acción.
También puede delegar la llamada a un servicio empresarial como un EJB. De esta forma puede abstraer los detalles del negocio. En aplicaciones "simples", generalmente no es dañino dejar esa parte y hacer todo en el frijol administrado. Sin embargo, una vez que llegas al punto en el que deseas cambiar la lógica comercial (por ejemplo, para un cliente diferente o para propósitos de demostración, etc.), tener un servicio sería más útil para que no necesites cambiar el sistema administrado. frijoles pero solo necesita escribir otra clase de implementación de una cierta interfaz comercial.
¿Cree que podemos escribir cualquier lógica en los métodos getter ?. Cuántas veces llamaron getter o setter en el ciclo de vida JSF.
Si la lógica de negocio necesita para ser ejecutado en cada llamada captador, y luego hacerlo (esto es sin embargo muy poco probable en el mundo real, le espera para el registro loco o (re casos de carga especiales perezoso)).Pero si la lógica de negocios necesita ejecutarse solo una vez por acción, evento, solicitud, sesión o alcance de la aplicación, definitivamente tiene que ejecutarse en otro lugar. Vea también this answer.
Cuantas veces se llama un captador debe ser su menor preocupación. El comprador no debería hacer otra cosa que devolver la propiedad en cuestión. Cuando se llama en el valor de salida, puede ser una vez por solicitud. Cuando se invoca el valor de entrada, puede ser dos veces por solicitud. Cuando se encuentre dentro de un componente datatable/repeat, multiplique las llamadas con la cantidad de filas. Cuando se encuentre dentro del attribtue renderizado, multiplique las llamadas con 6 ~ 8 veces.
¿Cuál es la forma convencional de escribir el faces-config.xml. He leído en un documento que dice que es una buena práctica escribir juntos la declaración de frijoles administrados y el caso de navegación para ese frijol. Será más legible.
Yo mismo uso muy raramente casos de navegación, por lo general no hay ninguno en mi faces-config.xml. Siempre publico de nuevo en la misma vista (devuelva null o void y luego renderizo/incluyo el resultado de manera condicional. Para la navegación de página a página no uso solicitudes POST (para las cuales los casos de navegación son obligatorios) simplemente porque eso es claro para UX (User eXperience; el botón de retroceso del navegador no se comporta como debería y las URL en la barra de direcciones del navegador están siempre un paso atrás porque son por defecto reenvíos, no redirecciones) y SEO (Search Engine Optimization; searchbots no indexa las solicitudes POST). Sólo uso outputlinks o incluso HTML plano <a> elementos para la navegación de página a página.
además, en JSF 2.0 hay técnicamente sin necesidad de definiciones de frijol gestionados y los casos de navegación en faces-config.xml. Ver también this answer.
Escribir el oyente de fase afectaría el tiempo de respuesta. Por ejemplo, estoy escribiendo una lógica para analizar el parámetro de solicitud en PhaseListener y hacer algo de lógica. ¿Hay algún consejo sobre esto?
Esto cae como con los filtros de servlet en la categoría de optimización prematura. Preocuparse por su desempeño generalmente no tiene sentido. Esto es por saldo generalmente solo una o dos líneas de código extra. Realmente no hay nada de qué preocuparse. Tendría problemas mucho más grandes cuando copie esa pieza de código en todas las clases. Si realmente crees que cuesta rendimiento, primero perfúlalo y luego podemos hablar de ello.
Gracias por la respuesta. – Krishna
De nada. – BalusC