Scribd
Cargar
18 vistas22 páginas

Clase 10 - Cliente Servidor, MVC Principios SOLID

Cargado por

nchavezalvarez
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
18 vistas22 páginas

Clase 10 - Cliente Servidor, MVC Principios SOLID

Cargado por

nchavezalvarez
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 22

Diseño de Sistemas

Agenda
• Cliente – Servidor
• MVC
• Principios SOLID

Cátedra Diseño de Sistemas – UTN BA 2


Cliente – Servidor (Estilo Arquitectónico)

Cátedra Diseño de Sistemas – UTN BA 3


Cliente - Servidor

Cátedra Diseño de Sistemas – UTN BA 4


Cliente - Servidor

Ventajas

• Cambios de funcionalidad Centralizados (Mantenibilidad)


• Testeable
• Mantenible

Desventajas

• El servidor puede ser un cuello de botella (Performance)


• Único punto de falla (Disponbilidad)

Cátedra Diseño de Sistemas – UTN BA 5


MVC (Patrón Arquitectónico)

Cátedra Diseño de Sistemas – UTN BA 6


MVC

Modelo-vista-controlador (MVC) es un patrón de arquitectura de software de interacción que separa la


arquitectura en tres componentes: el modelo, la vista y el controlador.

Cátedra Diseño de Sistemas – UTN BA 7


MVC - Modelo

Está vinculado con la representación de los datos con los cuales el sistema opera. Está relacionado a la lógica y
las reglas del negocio.

• Encapsula el estado del sistema

• Gestiona todos los accesos a dichos datos (consultas, actualizaciones, etc.)

• Valida la especificación de la lógica detallada en el “negocio”

• Envía a la Vista, a través del controller, los datos solicitados para que sean visualizados

Cátedra Diseño de Sistemas – UTN BA 8


MVC - Controlador

Responde a eventos (usualmente acciones del usuario) e invoca peticiones al modelo cuando se hace alguna
solicitud sobre los datos.

• Es el intermediario entre el modelo y la vista

• Define el comportamiento del sistema

• Traduce acciones del usuario a actualizaciones del modelo

• Es el gestor del ciclo de vida del sistema

• Responde a eventos

• Invoca peticiones al modelo


Cátedra Diseño de Sistemas – UTN BA 9
MVC - Vista

Presenta los datos y su forma de interactuar en un formato adecuado para el usuario.

• Posee lógica para poder representar los datos de la forma más “amigable” para el usuario

• Envía acciones del usuario al controlador

• Solicita actualizaciones al modelo a través del controller

• La comunicación entre la vista y el controlador se realiza mediante objetos de transferencia (DTO - Data
Transfer Objects)

Cátedra Diseño de Sistemas – UTN BA 10


MVC - Web

Cátedra Diseño de Sistemas – UTN BA 11


MVC – Validación de Datos

¿Dónde se validan los datos?

• EN CADA CAPA. Esto se lo denomina validación en profundidad.

• En la vista se puede validar campos requeridos y consistencia (números y/o letras donde corresponda, entre
otras cosas).

• En el controlador se debería volver a validar la consistencia de los datos y los campos requeridos. También
se puede realizar una validación adicional contra un servicio externo.

• En el modelo se deberían realizar las validaciones explícitas del negocio.

Cátedra Diseño de Sistemas – UTN BA 12


MVC – Ventajas y Desventajas

Ventajas

• Buena separación de intereses (concerns)


• Reusabilidad de Vistas y Controladores
• Flexibilidad

Desventajas

• Mayor complejidad de los Sistemas


• No siempre útil en aplicaciones con “Poca Interactividad” o con “Vistas Simples”
• Difícil de Testear “como un todo”

Cátedra Diseño de Sistemas – UTN BA 13


Principios SOLID

Cátedra Diseño de Sistemas – UTN BA 14


Principios SOLID

Son principios básicos de Programación Orientada a Objetos y Diseño de Sistemas que nos ayudan a obtener
mejores diseños implementando una serie de reglas o principios.

Nos ayudan a evitar la generación de “Código Sucio”

Cátedra Diseño de Sistemas – UTN BA 15


Principios SOLID

Single
Responsibility
Principle

Dependency
Open Closed
Inversion
Principle
Principle

SOLID

Interface Liskov
Segregation Substitution
Principle Principle

Cátedra Diseño de Sistemas – UTN BA 16


SOLID - Single Responsibility Principle

• Cada clase debe tener responsabilidad sobre una sola parte de la funcionalidad del software.

• Esta responsabilidad debe estar encapsulada por la clase, y todos sus servicios deben estar estrechamente
alineados con esa responsabilidad.

Evitar la clase “Dios” propiciando la alta Cohesión

Cátedra Diseño de Sistemas – UTN BA 17


SOLID - Open Closed Principle

• Las entidades deben estar abiertas para la expansión, pero cerradas para su modificación.

• Se basa en la implementación de herencias y el uso de interfaces para resolver el problema.

Se sugiere evitar la utilización excesiva de los “switchs” y propiciar el polimorfismo entre objetos

Cátedra Diseño de Sistemas – UTN BA 18


SOLID - Liskov Substitution Principle

“Cada clase que hereda de otra puede usarse como su superclase sin necesidad de conocer las diferencias entre
las clases derivadas.”

Se debería utilizar correctamente la herencia

Cátedra Diseño de Sistemas – UTN BA 19


SOLID – Interface Segregation Principle

• Los clientes de un componente sólo deberían conocer de éste aquellos métodos que realmente usan y no
aquellos que no necesitan usar.

• Muchas interfaces cliente específicas son mejores que una interfaz de propósito general.

Se debería propiciar un diseño orientado a interfaces, para mantener el acoplamiento entre clases al
mínimo posible, y también evitar generar interfaces extensas (con muchos métodos)

Cátedra Diseño de Sistemas – UTN BA 20


SOLID – Dependency Inversion Principle

“Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de
abstracciones. Es una forma de desacoplar módulos.”

Se sugiere utilizar inyectores de dependencias

Lectura sobre inyección de dependencias

Cátedra Diseño de Sistemas – UTN BA 21


Gracias

22

También podría gustarte