Capas arquitectura cliente servidor

sistema de información es un sistema que recopila y guarda información. No nos preocuparemos de obtener buenos diseños a nivel componentes de cada capa sino de dar un buen sistema de información desde el punto de vista arquitectónico. Patrones de la arquitectura multicapa o de arquitectura de aplicaciones empresariales. Estas manejan datos persistentes, que son accedidos concurrentemente, poseen una gran cantidad de lógica de negocio.
Su acceso se produce a través de elaboradas interfaces de usuario. Suelen tener necesidades de integración con otras aplicaciones. Los patrones son soluciones simples y elegantes a problemas específicos del diseño de software OO, se desentienden de EDA y diseños específicos de un dominio. Se identifican por las clases e instancias participantes, roles y colaboraciones y la distribución de responsabilidades.

AUXILIARES

MVC:

divide una aplicación interactiva en tres componentes: modelo (funcionalidad básica y los datos) vistas (muestran/recogen información al/del usuario) controladores (median entre vistas y modelo). variante activa o pasiva.

V:

Modelo independiente de la representación de la salida y del comportamiento de la entrada, pudiendo haber múltiples vistas del mismo modelo. Cambios independientes en interfaz/lógica.

C:

Complejidad. Se trata de un caso particular del patrón Observador. Las vistas se anidan en MVC siendo un caso de patrón compuesto.

FACHADA:

Si la dependencia fuera asociación navegada, la responsabilidad de crear los elementos accedidos, no debería recaer sobre el objeto que los accede => Se delega en otro objeto para crearlo: patrón factoría abstract. El patrón fachada facilita estructurar un sistema en subsistemas. Cada subsistema debe implementar sus responsabilidades evitamos sistemas monolíticos.

Factoría ABSTRACTA:

proporciona una interfaz para crear familias de objetos relacionados o que dependen entre sí, sin especificar sus clases concretas.

V:

Aísla las clases concretas que se crean en una
aplicación y se manejan a través de los interfaces que implementan. Facilita el intercambio de familias de productos. Promueve la consistencia entre productos.

C:

Nuevos tipos de productos provocan la redefinición de la factoría.
Arquitectura de una capa no divide al sistema en presentación, negocio e integración. Es conceptualmente sencillo pero: No se puede modificar ni la interfaz de usuario, ni la lógica del negocio sin afectar a las demás capas. Complicación fáctica.
Arquitectura de dos capas diferencia entre la capa de presentación y el resto del sistema (No diferencia negocio de integración). Permite cambios en el interfaz de usuario o en el resto del sistema sin interferencias mutuas. Simplicidad fáctica. Pero: mayor complicación arquitectónica que la de una capa y no se puede modificar la lógica del negocio o la representación de los datos sin interferencias mutuas.

Arquitectura multicapa:

capa de clientes (representa a todos los dispositivos o clientes del sistema). Capa de presentación(encapsula toda la lógica de presentación), de negocio(proporciona los servicios del sistema), de integración (responsable de la comunicación con recursos y sistemas externos) y capa de recursos (contiene los datos del
negocio y recursos externos). Son todas capas lógicas. Podrían estar en máquinas distintas. Se puede modificar cualquier capa sin afectar a las demás. Más complejo que las anteriores.

V:

Integración y reusabilidad, Encapsulación, Distribución, Particionamiento, Escalabilidad, Mejora del rendimiento, Mejora de la fiabilidad, Manejabilidad, Incremento en la consistencia y flexibilidad, Soporte para múltiples clientes, Desarrollo independiente, Desarrollo rápido, Empaquetamiento, Configurabilidad.

C:

Posible pérdida de rendimiento y escalibilidad, riesgos de seguridad, Gestión de componentes. Patrones relacionados:
Transferencia (capa de negocio) Independizar el intercambio de datos entre capas. Si queremos independizar las capas, éstas no pueden tener conocimiento de la representación de las entidades. De cada capa.

Cuando:

No se desee conocer la representación interna de una entidad dentro de una capa.

V:

independiza capas.

C:

Aumenta mucho el número de objetos del sistema.

Data Access Object(DAO)

(capa de integración) Permite acceder a la capa de datos, proporcionando representaciones orientadas a objetos a sus clientes. Este patrón fuerza a Conocer los mecanismos de acceso del sistema de gestión de datos y Conocer la representación de los datos en el sistema de gestión de datos. Así, se podría cambiar la capa de datos, sin afectar a la capa de negocio. Solamente habría que actualizar la capa de integración. Es fundamental que los DAOs capturen y lancen las excepciones correspondientes al acceder a los recursos externos Cuando:
Se quiera independizar la representación y acceso a los datos de su procesamiento V:
Independiza el tratamiento de los datos de su acceso y estructura. Permite independizar la capa de negocio de la de datos.

C:

Aumenta el número de objetos del sistema   Servicio de aplicación (capa de negocio) Centraliza lógica del negocio que debe estar en algún sitio ni clientes, ni facahda, se incluye en servicios de la aplicación.

Cuando:

Se quiera representar una lógica del negocio que actúe sobre distintos servicios u objetos del negocio. Agrupar funcionalidades relacionadas o encapsular lógica no representada por objetos del negocio. Los servicios de aplicación no suelen tener atributos para hacerlos más ligeros.  

V:

Centraliza lógica del negocio. Mejora la reusabilidad del código. Evita duplicación de código. Simplifica la implementación de fachadas.

C:

Introduce un nivel más de indirección.