Informática

REAL WORLD JAVA
La interfaz fachada de servicio debe ser utilizable como un servicio remoto, la firma de los métodos expuestos deben ser estables y siguen siendo compatibles, aunque larealización de los cambios de los componentes. La solución es interfaz de negocio a distancia sólo debe proporcionarse si se va a utilizar desde fuera de la máquina virtual de Java (JVM) y no se inyecta en unServet o componente web. Este es el caso con un Eclipse o NetBeans plataforma de cliente enriquecido (RCP) de aplicación, por ejemplo. Los métodos Fachada de servicio están diseñados desde laperspectiva de dominio y, por tanto, amplia; cada interacción entre el usuario y el sistemas es una transacción comercial.
El uso de patrones en Java hacen ineficiente y difícil mantener aplicaciones, laflexibilidad y disociación de determinados servicios y recursos fueron mal interpretados y condujo a un exceso de aplicaciones de ingeniería. El problema es el acceso a los componentes de lógica denegocios debe ser lo mas cómodo y coherente posible. Solo una API amplia puede cumplir los requisitos, que debe ser comprensibles por los expertos del dominio; otro problema es la latencia de red ya que esdemasiado alto para el acceso y es difícil de ejecutar.

Application Servicie (Servicio de Fachada) solía ser una parte obligatoria de todas las aplicaciones. Se utilizó para aislar la capa depresentación de la grada de negocios. Los parámetros del servicio de aplicación o eran primitivas u objetos de transferencia de datos. La separación entre la infraestructura técnica y la lógica de negociono se le dio, por lo que en la mayoría de los casos, el servicio de aplicación era más que un delegado a un objeto viejo y simple Java que implementa la lógica de negocio valiosa. Esta separación yano es necesario, porque la fachada de servicio es un POJO limpia que sólo depende de unos pocos anotaciones. La distinción entre un controlador y un servicio puro es borrosa también. Incluso la...