Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Programación en N Capas .Net
Ähnlich wie Programación en N Capas .Net (20)
Mehr von Germán Küber
Mehr von Germán Küber (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Programación en N Capas .Net
- 5. Objetivos de la Iteración Esquema del sistema Identificar riesgos Arquitecturas candidatas Casos de Uso importantes Requisitos Software
- 6. Capa de Presentación Capa de Negocio Capa de Acceso a Datos
- 7. Capa de Presentación Capa de Aplicación Capa de Acceso a Datos Capa de Servicios Distribuidos Capa de Modelo de Dominio Servicios Externos Infraestructura Transversal
- 16. Entity Framework
- 17. Pruebas de Integración [Fact] public void Add_User() { var newUser = new User(); var userRepository = new UserRepository(); userRepository.AddUser(newUser); var dbUser = userRepository.GetById(newUser.Id); Assert.Equal(newUser, dbUser); }
- 21. Entidad Vs Objeto Valor
- 22. Agregados
- 24. Consideraciones de Diseño de Dominio
- 30. Repositorios en Capa de Aplicación
- 32. Patrones de Diseño para Presentación
- 33. Patrón MVC (Modelo Vista Controlador)
- 38. Conclusiones
Hinweis der Redaktion
- Patrón de Inversión de Control (IoC): Delegamos a un componente o fuente externa, la función de seleccionar un tipo de implementación concreta de las dependencias de nuestras clases. En definitiva, este patrón describe técnicas para soportar una arquitectura tipo „plug-in‟ donde los objetos pueden buscar instancias de otros objetos que requieren y de los cuales dependen. Patrón Inyección de Dependencias (Dependency Injection, DI): Es realmente un caso especial de IoC. Es un patrón en el que se suplen objetos/dependencias a una clase en lugar de ser la propia clase quien cree los objetos/dependencias que necesita. El término fue acuñado por primera vez por Martin Fowler.
- * Active record: Es decir, un Active Record deposita la lógica de su persistencia dentro del propio dominio del objeto. Este patrón de diseño está puesto en práctica en muchas implementaciones de lenguajes dinámicos como Ruby y es usado ampliamente hoy en día por la comunidad de desarrolladores. Dentro de la tecnología .NET, hoy en día existen numerosas implementaciones como Castle Active Record, .NetTiers Application Framework o LLBLGenPro por poner algunos ejemplos. Sin embargo, uno de los inconvenientes más grandes de este patrón viene de su propia definición, al no separar conceptualmente el transporte de datos de sus mecanismos de persistencia. Si pensamos en arquitecturas orientadas a servicios dónde precisamente una separación entre los contratos de datos y las operaciones sobre los mismos es uno de los pilares de SOA, veremos que una solución como esta (Active Record) no es apropiada y en muchas ocasiones es extremadamente difícil de implementar y mantener. Otro ejemplo donde una solución basada en „Active Record‟ no es en principio una buena elección es aquella en la que no hay una relación 1:1 entre las tablas de la base de datos y los objetos Active Record dentro de nuestros modelos de dominio, o bien la lógica que estos objetos tienen que disponer es algo compleja.
- Normas - La lógica de Aplicación no deberá incluir ninguna lógica del Dominio, solo tareas de coordinación relativas a requerimientos técnicos de la aplicación, como coordinación de llamadas a Repositorios para persistir datos, conversiones de formatos de datos de entrada a entidades del Dominio, y en definitiva, llamadas a componentes de Infraestructura para que realicen tareas complementarias de aplicación. - Nunca deberá poseer estados que reflejen la situación de los procesos de negocio, sin embargo si puede disponer de estados que reflejen el progreso de una tarea del software. Ventajas del uso de la Capa de Aplicación Cumplimos el principio de “Separation of Concerns”, es decir, aislamos a la Capa de Dominio de tareas/requerimientos propios del software, tareas de „fontanería‟ que realmente no es lógica del negocio, sino aspectos de integración tecnológica, coordinación de la persistencia de datos, formatos de datos, optimización del rendimiento, etc.
- Normas - La lógica de Aplicación no deberá incluir ninguna lógica del Dominio, solo tareas de coordinación relativas a requerimientos técnicos de la aplicación, como coordinación de llamadas a Repositorios para persistir datos, conversiones de formatos de datos de entrada a entidades del Dominio, y en definitiva, llamadas a componentes de Infraestructura para que realicen tareas complementarias de aplicación. - Nunca deberá poseer estados que reflejen la situación de los procesos de negocio, sin embargo si puede disponer de estados que reflejen el progreso de una tarea del software. Ventajas del uso de la Capa de Aplicación Cumplimos el principio de “Separation of Concerns”, es decir, aislamos a la Capa de Dominio de tareas/requerimientos propios del software, tareas de „fontanería‟ que realmente no es lógica del negocio, sino aspectos de integración tecnológica, coordinación de la persistencia de datos, formatos de datos, optimización del rendimiento, etc.
- El patrón Model-View-Presenter (MVP) separa el modelo del dominio, la presentación y las acciones basadas en la interacción con el usuario en tres clases separadas. La vista le delega a su presenter toda la responsabilidad del manejo de los eventos del usuario. El presenter se encarga de actualizar el modelo cuando surge un evento en la vista, pero también es responsable de actualizar a la vista cuando el modelo le indica que ha cambiado. El modelo no conoce la existencia del presenter.
- Normas - La lógica de Aplicación no deberá incluir ninguna lógica del Dominio, solo tareas de coordinación relativas a requerimientos técnicos de la aplicación, como coordinación de llamadas a Repositorios para persistir datos, conversiones de formatos de datos de entrada a entidades del Dominio, y en definitiva, llamadas a componentes de Infraestructura para que realicen tareas complementarias de aplicación. - Nunca deberá poseer estados que reflejen la situación de los procesos de negocio, sin embargo si puede disponer de estados que reflejen el progreso de una tarea del software. Ventajas del uso de la Capa de Aplicación Cumplimos el principio de “Separation of Concerns”, es decir, aislamos a la Capa de Dominio de tareas/requerimientos propios del software, tareas de „fontanería‟ que realmente no es lógica del negocio, sino aspectos de integración tecnológica, coordinación de la persistencia de datos, formatos de datos, optimización del rendimiento, etc.
- Diseñar una estrategia apropiada de propagación de excepciones que envuelva o reemplace las excepciones (errores internos), o añada información extra según se requiera. Por ejemplo, permitir que las excepciones suban hacia las capas superiores hasta llegar a las „capas frontera‟ (como Servicios-Web o Capa de Presentación Web ASP.NET), donde dichas excepciones serán registradas (logs) y transformadas según sea necesario antes de pasarlas a la siguiente capa (normalmente, antes de que lleguen a la capa de presentación o interfaz gráfico de usuario).