D01 - Arquitectura “N” Capas

28-11-11 Wiki Arquitectura - D01 - Arquitectura “N” Capas

1/20siteworkit/sites/Arquitectura/…/D01 - Arquitectura “N” Capas.aspx

Este documento está orientado a los desarrolladores que implementanAplicaciones en ING Chile.

Wiki Arquitectura Este sitio: Wiki Arquitectura

Arquitectura y Test ing > Wiki A rquitectura > Paginas Wiki > D01 - A rquitectura “N” Capas

D01 - Arquitectura “N” Capas

Marco Normativo Arquitectura 2011

Documento de Arquitectura de

Referencia

D01 - Arquitectura “N” Capas

Versión 1.0.0.005 de octubre de 2011



�

�

Historial de Versiones

Elaborado por Revisado por Autorizadopor

Versión Fecha Comentarios

Arquitectura deSistemas

� � 1.0.0.0

�

03/09/2011 Creación deldocumento.

1.��Contenido

1. Contenido

2. Prefacio

2.1. Acerca del Documento

2.2. Alcance

2.3. Clasificación del Documento

2.4. Grupos de Interés

2.5. Definiciones, Acrónimos y Abreviaturas

2.6. Referencias

3. Arquitectura Marco en “N” Capas

3.1. “N” Capas de la Arquitectura Marco

3.2. Arquitectura en “N” Capas

3.2.1. Capa de Presentación

3.2.2. Capa de Negocios

3.2.3. Capa Acceso a Datos

3.2.4. Capa Transversal

3.2.1. Capa de Seguridad

4. Implementación de Estructura “N” Capas y Nomenclatura

4.1. Diseño de la Solución

4.1.1. La Carpeta “1 – Layers”


4.1.3. Capa de Servicios Distribuidos




4.1.4. Capa de Negocio

4.1.5. Capa de Acceso a Datos

4.1.6. Recomendaciones de Estructura para la Solución

4.1.1. Recomendaciones para Aplicaciones Web ASP.NET

4.1.2. Recomendaciones para Aplicaciones Web ASP.NET MVC

4.1.3. Recomendaciones para RIA Silverlight

4.1.4. Recomendaciones para Aplicaciones de Escritorio Rico con WPF

4.1.5. Recomendaciones para el Agente de Servicio Interno (de Presentación)

4.1.6. Recomendaciones para la Capa de Servicios Distribuidos

4.1.7. Recomendaciones para la Capa de Infraestructura de Persistencia y Acceso a Datos

2.��Prefacio

2.1.��Acerca del Documento

Este documento pretende describir una arquitectura marco de referencia sobre la que se pueda desarrollar lasaplicaciones a medida y establece un conjunto de normas, mejores prácticas y guías de desarrollo para utilizar.NET de forma adecuada y, sobre todo, homogénea dentro de la compañía.

2.2.��Alcance

El alcance del Documento está definido según los estándares de arquitectura de “Microsoft Architecture“, juntocon las normas definidas por el departamento de Arquitectura.

�

2.3.��Clasificación del Documento

Este documento se clasifica como NORMA. No implementar las definiciones de este documento afecta el estadode la Adherencia del dominio Aplicación, Integración, Interacción, Seguridad en el ICR.

2.4.��Grupos de Interés

Grupo Interés



Grupo Interés

Desarrollo Uso como referencia para el desarrollo de aplicaciones

Seguridad �

Ingeniería deSistemas

�

Arquitectura Uso para definición en proyectos

Modeladores de Datos Uso como referencia para el desarrollo de aplicaciones

Analistas de Sistemas Uso como referencia para el desarrollo de aplicaciones

Proveedores Uso como referencia para el desarrollo de aplicaciones

2.5.��Definiciones, Acrónimos y Abreviaturas

Término Significado

� �

�

2.6.��Referencias

Documento Ubicación y nombre de archivo.

Centro de Arquitectura -MSDN

http://msdn.microsoft.com/es-es/architecture/default.aspx

3.��Arquitectura Marco en “N” Capas

Esta sección define de forma global la arquitectura marco en “N” Capas así como ciertos patrones y técnicas atener en cuenta para la integración de dichas capas.

3.1.��“N” Capas de la Arquitectura Marco

En el nivel más alto y abstracto, la vista de arquitectura lógica de un sistema puede considerarse como unconjunto de servicios agrupados en diversas capas, similar al siguiente esquema.

�

Vista de arquitectura lógica de un sistema en “N” Capas

Es importante mantener y velar respecto a las responsabilidades en cada una de las capas de la arquitectura.

3.2.��Arquitectura en “N” Capas



3.2. Arquitectura en “N” Capas

El objetivo de esta arquitectura marco es estructurar de forma limpia y clara la complejidad de una aplicaciónempresarial basada en las diferentes capas de la arquitectura, siguiendo el patrón N-Capas. El patrón N-Capasdistingue diferentes capas y subcapas internas en una aplicación, delimitando la situación de los diferentescomponentes por su tipología.

En concreto, las capas y subcapas propuestas para aplicaciones en Capas son:

�

Arquitectura en Capas

�

Ͳ Capa de PresentaciónR Subcapas de Componentes Visuales (ASP.NET)R Subcapas de Proceso de Interfaz de Usuario (Controladores y similares)

Ͳ Capa de Negocios (Servicios Web)R Fachada de Servicios para publicar la Capa de NegocioR Componentes de Negocio (incluye Workflow)

Ͳ Capa de Acceso a DatosR Factory de Acceso a DatosR Componentes de Acceso a Datos

R Componentes de Acceso a ORMR Tecnología ORM (Entity Framework)

Ͳ Capa Transversal

R LoggingR Exception HandlingR Entidades de Negocio

R DTO (Objetos de transferencia de datos)Ͳ Capa de Seguridad

R Security ManagerR Single Sign-on con Active Directory

�

�


Esta capa es responsable de mostrar información al usuario e interpretar sus acciones.

Los componentes de las capas de presentación implementan la funcionalidad requerida para que los usuariosinteractúen con la aplicación. Normalmente es recomendable subdividir dichos componentes en varias subcapasaplicando patrones de tipo MVC, MVP, o M-V-VM:

x Subcapa de Componentes Visuales (Vistas ASP.NET): Estos componentes proporcionan elmecanismo base para que el usuario utilice la aplicación. Son componentes que formatean datos en

cuanto a tipos de letras y controles visuales, y también reciben datos proporcionados por el usuario.

x Subcapa de Controladores: Para ayudar a sincronizar y orquestar las interacciones del usuario,puede ser útil conducir el proceso utilizando componentes separados de los componentes

propiamente gráficos. Esto impide que el flujo de proceso y lógica de gestión de estados esté



propiamente gráficos. Esto impide que el flujo de proceso y lógica de gestión de estados estéprogramada dentro de los propios controles o formularios visuales y permite reutilizar dicha lógica ypatrones desde otras interfaces o “vistas”. También es muy útil para poder realizar pruebas unitarias

de la lógica de presentación. Estos “Controladores” son típicos de los patrones MVC y derivados.

x Subcapa de Servicios (WebService/WCF): Permite exponer funcionalidades definidas por elnegocio y establecer comunicaciones remotas con distintas aplicaciones que así lo requieran. Esta

subcapa utiliza como mecanismo de comunicación Web Services o WCF.�

3.2.2. Capa de Negocios

Esta capa es la encargada de procesar la lógica determinada por el negocio, tiene la responsabilidad de recibirinformación, procesarla y convertir las entidades de negocio en objetos de transmisión de datos para retornar lainformación requerida, además es la encargada de alojar y ejecutar los flujos de trabajo (opcional)

�

La capa de negocios se comunica con la capa de datos a través de una fábrica de acceso a datos, quienproporciona una fachada para persistencia y acceso a los datos. Una vez procesada la información, se encarga deretornarla a la capa de presentación a través de la fachada de servicios, o directamente a la componente depresentación a través de los Controller.

3.2.3. Capa Acceso a Datos

Esta capa proporciona la capacidad de persistir datos así como lógica para acceder a ellos. Pueden ser datospropios del sistema o incluso acceder a datos expuestos por sistemas externos (Servicios Web externos, etc.).Así pues, esta capa de persistencia de datos expone el acceso a datos a las capas superiores, normalmente alas capas del Negocio. Esta exposición deberá realizarse de una forma desacoplada a través de una Factory deAcceso a Datos.

x Subcapa de Factory de Acceso a Datos: Centraliza en una clase constructora la creación de

objetos de un tipo determinado para acceder a datos.

x Subcapa de Componentes de Acceso a Datos: Componentes desarrolladas con Data Access

Application Block de la Enterprise Library para acceder a datos.

x Subcapa de Componentes de Acceso a ORM: Componentes que permiten desacoplar la

implementación de una tecnología ORM determinada. Permiten determinar las acciones posibles autilizar sobre el ORM.

x ORM Entity Framework: Mapeo relacional de objetos, permite el “mapeo” de un modelo dedatos relacional a un modelo de objetos.

x Subcapa de Agentes de Servicios remotos/externos: Cuando un componente de negocio deutilizar funcionalidad proporcionada por servicios externos/remotos (normalmente Servicios Web), se

debe implementar código que gestione la semántica de comunicaciones con dicho servicio particular o

incluso tareas adicionales como mapeos entre diferentes formatos de datos. Los Agentes de Serviciosaíslan dicha idiosincrasia de forma que, manteniendo ciertas interfaces, sería posible sustituir el

servicio externo original por un segundo servicio diferente sin que nuestro sistema se vea afectado. Laimplementación se realiza en la capa de Datos.





Proporcionan capacidades técnicas genéricas que dan soporte a capas superiores. En definitiva, son “bloques deconstrucción” ligados a una tecnología concreta para desempeñar sus funciones.

�

Existen muchas tareas implementadas en el código de una aplicación que se deben aplicar en diferentes capas.Estas tareas o aspectos transversales implementan tipos específicos de funcionalidad que pueden seraccedidos/utilizados desde componentes de cualquier capa. Los diferentes tipos/aspectos transversales máscomunes son: tareas de gestión de operaciones (políticas, logging, trazas, monitorización, configuración, etc.).

x Subcapa de Logging: Capa con la lógica para la implementación de logging a través del Logging

Application Block de la Enterprise Library. Estas componentes pueden ser reutilizables en distintosproyectos.

x Subcapa de Exceptión Handling: Componentes con la lógica para capturar y procesar erroresproducidos dentro de la aplicación. La implementación de Exception Handling es a través de

Exception Handling Application Block de la Enterprise Library. Estas componentes pueden ser

reutilizables en distintos proyectos.

�

Dentro de la capa transversal se consideran también:

x Entidades de Negocio: Permiten modelar el negocio en base a entidades. Estas no tienendependencia de alguna tecnología determinada (ORM).

x DTO: Objetos para la transmisión o transferencia de datos. Estructuras de datos complejas con los

datos necesarios para las capas superiores.

3.2.1. Capa de Seguridad

La capa de seguridad es la responsable de brindar seguridad e integridad a la aplicación y a los datos que estámaneja.

x Subcapa de Autenticación:: Componentes que permiten utilizar la autenticación basada enActive Directory y/u otro mecanismo en caso de necesitar autenticación de usuarios externos seintegrará con servicios ACIC..

x Subcapa de Autorización: Componentes que permiten la autorización de usuarios a través de laintegración con el servicio Security Manager. Permite usar roles, tareas, operaciones dentro de lasaplicaciones.

4. Implementación de Estructura “N” Capas y

Nomenclatura

Para implementar una Arquitectura en Capas (según el modelo lógico definido), hay una serie de pasos quedebemos realizar:

1. La solución debe estar organizada y mostrar de forma clara y obvia donde está situada la

implementación de cada capa y subcapa.



implementación de cada capa y subcapa.2. Cada capa tiene que estar correctamente diseñada.

3. Existirán capas transversales de patrones y tecnologías a ser utilizados a lo largo de toda la aplicación.

Es un seedwork (en lugar de framework), en definitiva, un código fuente que será reutilizado tambiénen otros proyectos futuros, así como ciertas clases base (Core) de las capas de Acceso a Datos.

4. La solución debe seguir una nomenclatura definida para cada parte de su estructura (capas, subcapas,

proyectos, y otros artefactos).

4.1. Diseño de la Solución

Teniendo una Solución, inicialmente crearemos la estructura de carpetas lógicas para albergar y distribuir losdiferentes proyectos. En la mayoría de los casos crearemos un proyecto (.DLL) por cada capa o subcapa, paradisponer así de una mayor flexibilidad y facilitar los posibles desacoplamientos. Sin embargo, esto ocasiona unnúmero de proyectos considerables, por lo que es realmente imprescindible ordenarlos/jerarquizarlos mediantecarpetas lógicas.

La nomenclatura a usar en la Arquitectura N-Capas se basa en la Convención de Nombres del documentoNormativo de Desarrollo C#.

La jerarquía inicial sería algo similar a la siguiente:

Jerarquía de Carpetas en Solución de Visual Studio

Empezando de arriba:

x La primera carpeta “0 – Modeling and Design”, contendrá los diferentes diagramas de Arquitectura

y Diseño, como diagramas de Capas (Layer) de la Arquitectura, y los diferentes diagramas UML de

diseño interno.

x La siguiente carpeta “1 – Layers”, contendrá las diferentes capas de la Arquitectura N-Capas, comose observa en la jerarquía anterior.

x La carpeta “2 – Database” (opcional), contendrá todos los elementos necesarios para poderdistribuir la base de datos de la solución, si es que tiene una. Estos elementos normalmente son

archivos de SQL (.sql) que contienen la estructura de la propia base de datos, de sus tablas, vistas;

así como también de funciones como procedimientos almacenados, y de población de tablas;adicionalmente se pueden tener archivos sql que permitan definir los permisos y otras configuraciones

necesarias para el adecuado comportamiento de la base de datos. Estos archivos sql pueden estar

contenidos dentro de un Proyecto de Base de Datos SQL Server (recomendado) si es que la base dedatos que se usará es MS SQL Server 2005 o superior.

x La carpeta “Solution Items” contendrá elementos distintos a los nombrados anteriormente necesarios

para el desarrollo de la aplicación. Puede contener documentos, archivos de texto, archivos de

diagramas en Visio, hojas de cálculo, cartas Gantt, entre otros.

La nomenclatura que se usará para el nombre de la solución será:

[Nombre de Solución], donde:

Ͳ [Nombre de Solución] es el nombre de la solución a desarrollar, normalmente es el nombre del aplicativo

o proyecto de negocio a desarrollar. Este debe estar en Pascal Case.

4.1.1. La Carpeta “1 – Layers”



Como se mencionó anteriormente, la carpeta “1 – Layers”, contendrá las diferentes capas de la Arquitectura N-Capas, a continuación se detallan las distintas capas que contendrá esta carpeta:

�


La primera capa, Presentación, contendrá los diferentes tipos de proyectos que pudiera hacer, es decir, proyectosde Escritorio-Ricos (WPF, WinForms, OBA), RIA (Silverlight, Flex), Web (ASP.NET WebForms, ASP.NET MVC)o Móvil (Windows Phone con Silverlight, BlackBerry), etc.

Capas de Presentación

�

La nomenclatura que se usará para la capa de presentación es la siguiente:

[País].[Empresa].[Nombre de Solución].[Tipo de Aplicación].[Tecnología].Client, donde:

Ͳ [País] es el código de país. Este debe ser de 2 letras todas en mayúscula.

Ͳ [Empresa] es�el�nombre de empresa. Este debe ser el nombre completo de la empresa o susiniciales relevantes y estar en Pascal Case

Ͳ [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.

Ͳ [Tipo de Aplicación] es el nombre del tipo de aplicación que puede ser:R Desktop, para las aplicaciones de escritorio rico.

R RIA, para las aplicaciones de Internet ricas.

R Web, para las aplicaciones Web, tanto intranet como Internet.R Mobile, para las aplicaciones Móviles.

Esta debe estar en Pascal Case.

Ͳ [Tecnología] es el nombre de la tecnología a usar para el desarrollo del tipo de cliente.

La nomenclatura detallada que usará para los distintos tipos de aplicación de la capa de presentación se muestraen la siguiente tabla:

Tipo deAplicación

Descripción Ejemplo

Escritorio

� WPF Aplicación de escritorio rico usandoWindows Presentation Foundation. Sunomenclatura debe ser:

[País].[Empresa].[Nombre deSolución].Desktop.WPF.Client

CL.Ing.Campanas.Desktop.WPF.Client

� OBA Aplicación de escritorio rico usando Office2003, 2007, o 2010. Su nomenclatura debeser:

[País].[Empresa].[Nombre deSolución].Desktop.OBA.Client

CL.Ing.Campanas.Desktop.OBA.Client

RIA



� Silverlight RIA usando Silverlight 3.0 o 4.0(recomendado). Su nomenclatura debe ser:

[País].[Empresa].[Nombre deSolución].RIA.Silverlight.Client

CL.Ing.Campanas.RIA.Silverlight.Client

� Flex RIA usando Flex. Su nomenclatura debeser:

[País].[Empresa].[Nombre deSolución].RIA.Flex.Client

CL.Ing.Campanas.RIA.Flex.Client

Web

� ASP.NETWebForms

Aplicación Web usando ASP.NETWebForms tradicional. Su nomenclaturadebe ser:

[País].[Empresa].[Nombre deSolución].Web.Forms.Client

CL.Ing.Campanas.Web.Forms.Client

� ASP.NETMVC

Aplicación Web usando ASP.NET MVC. Sunomenclatura debe ser:

[País].[Empresa].[Nombre deSolución].Web.MVC.Client

CL.Ing.Campanas.Web.MVC.Client

Móvil

� WinPhoneconSilverlight

Aplicación Móvil para Windows Phoneusando Silverlight 4.0. Su nomenclaturadebe ser:

[País].[Empresa].[Nombre deSolución].Mobile.Silverlight.Client

CL.Ing.Campanas.Mobile.Silverlight.Client

� BlackBerry Aplicación Móvil para BlackBerry. Sunomenclatura debe ser:

[País].[Empresa].[Nombre deSolución].Mobile.BlackBerry.Client

CL.Ing.Campanas.Mobile.BlackBerry.Client

En el caso de que se requiera que el proyecto consuma de forma remota a través de los servicios distribuidos lacapa de negocio, es necesario construir un proyecto de Agentes de Servicios, a continuación se detallan losescenarios en donde se requiere este proyecto:

x Cuando se va a desarrollar una aplicación de Escritorio Rico (WPF, OBA).

x Cuando se va a desarrollar una RIA (Silverlight, Flex)

x Cuando se va a desarrollar una aplicación Móvil (Windows Phone con Silverlight o Widgets de

BlackBerry).

x Cuando se va a desarrollar una aplicación Web (ASP.NET Web Forms, ASP.NET MVC), que por

políticas de seguridad o restricciones de la infraestructura física tiene que estar desplegada en un nivelde servidores distintos al de la capa de Negocio.

�

1. Cuando se está desarrollando una aplicación Web, o una aplicación de Escritorio Rico, el proyecto deAgentes de Servicios debe estar ubicado directamente bajo la carpeta de la capa de Presentación. La

nomenclatura que se usará para este proyecto es el siguiente:



nomenclatura que se usará para este proyecto es el siguiente:

[País].[Empresa].[Nombre de Solución].Presentation.ServiceAgent, donde:

R [País] es el código de país. Este debe ser de 2 letras todas en mayúscula.

R [Empresa] es�el�nombre de empresa. Este debe ser el nombre completo de la empresa o sus

iniciales relevantes y estar en Pascal CaseR [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.

2. Cuando se está desarrollando una RIA con Silverlight, el proyecto de Agentes de Servicios debe estar

ubicado dentro de la subcarpeta “RIA/Silverlight Client”. La nomenclatura que se usará para esteproyecto es el siguiente:

[País].[Empresa].[Nombre de Solución].RIA.Silverlight.ServiceAgent, donde:


R [Empresa] es�el�nombre de empresa. Este debe ser el nombre completo de la empresa o susiniciales relevantes y estar en Pascal Case

R [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.

3. Cuando se está desarrollando una RIA con Silverlight, el proyecto de Agentes de Servicios debe estarubicado dentro de la subcarpeta “Mobile/Silverlight Mobile”. La nomenclatura que se usará para

este proyecto es el siguiente:

[País].[Empresa].[Nombre de Solución].Mobile.Silverlight.ServiceAgent, donde:

R [País] es el código de país. Este debe ser de 2 letras todas en mayúscula.R [Empresa] es�el�nombre de empresa. Este debe ser el nombre completo de la empresa o sus

iniciales relevantes y estar en Pascal Case

R [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.4. Cuando se está desarrollando una RIA con Flex, o una aplicación Móvil con BlackBerry, el agente de

servicio es parte del proyecto del tipo de aplicación.


Esta capa es donde implementaremos los servicios WCF (normalmente Servicios Web) para poder accederremotamente a los componentes del Servidor de Negocio. Es importante destacar que esta capa de ServiciosDistribuidos es opcional, puesto que en algunos casos (como una capa de presentación Web ASP.NET, que notenga restricciones de seguridad, ni de infraestructura física), es posible que se acceda directamente a loscomponentes de la capa de Negocio, si el servidor Web de ASP.NET está en el mismo nivel de servidores que loscomponentes de negocio.

En el caso de hacer uso de servicios distribuidos para accesos remotos, la estructura es la siguiente:

�

Uso de Servicios Distribuidos

�

La capa de presentación contiene los siguientes proyectos:

x Un proyecto para las Interfaces de Servicio de los Servicios Distribuidos, donde se declaran lasinterfaces/contratos de los servicios. Este proyecto debe ser de tipo de Librería de Clases.El proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices, donde:





R [Empresa] es�el�nombre de empresa. Este debe ser el nombre completo de la empresa o sus


x Un proyecto para los contratos de datos del servicio de los Servicios Distribuidos, donde se declarantodos los DTOs y las clases de Mensajería usados como parámetros de entrada o de retorno en las

operaciones de las Interfaces de Servicio. Este proyecto debe ser de tipo de Librería de Clases.El proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.Contracts, donde:




x Un proyecto para la implementación de las Interfaces de Servicio como WCF. Este proyecto puedeser de tipo Librería de Servicios WCF.La nomenclatura que debe tener el proyecto es la siguiente:[País].[Empresa].[Nombre de Solución].DistributedServices.Impl, donde:



x Un proyecto para hospedar (Host) los Servicios WCF, es decir, el proceso donde se ejecuta ypublica el servicio WCF. Ese proyecto/proceso puede ser de tipo WebSite de IIS (cuando se

hospeda como Servicio Web mediante HTTP/HTTPS), un Servicio Windows (cuando se hospedacomo Servicio usando otros protocolos/puertos como NetTCP), o realmente cualquier tipo deproceso, tales como una aplicación de consola, pero se recomienda este tipo de proyecto solo

cuando está en un ambiente de pruebas unitarias.El proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.Host, donde:



R [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.Si se tiene varios tipos de endpoints (HTTP/HTTPS, NetTCP, etc.), para el consumo de los serviciosWCF, seguir los siguientes lineamientos:

R Usar el tipo de proyecto Aplicación de Servicios WCF, si es que se va a hospedar como

HTTP/HTTPS, NetTCP, y/u otros, y se cuenta con IIS 7.0 o superior, usando lanomenclatura anteriormente descrita.

R Si no se cuenta con IIS 7.0 o superior, usar los siguientes tipos de proyectos y nomenclaturas:

� Para hospedar los Servicios WCF en NetTCP u otro protocolo/puerto distintos aHTTP/HTTPS usar un Servicio Windows con la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.WinService.Host

� Para hospedar los Servicios WCF en HTTP/HTTPS usar el tipo de proyectoAplicación de Servicios WCF con la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.IIS.Host

Debemos aclarar que el proyecto de Host debe ser único por aplicación/servicio y por tecnología de Hostusada.

En el caso de que se cuente con varios módulos en la solución deberemos usar los siguientes lineamientos,



En el caso de que se cuente con varios módulos en la solución deberemos usar los siguientes lineamientos,excepto para el proyecto Host, ya que, como se comenta en el párrafo anterior, este proyecto debe ser único poraplicación/solución y tecnología:

Capa de Servicios Distribuidos con Módulos

�

x Se deben crear subcarpetas por cada módulo que contenga la solución. Cada subcarpeta debe estaren Pascal Case.

x Cada subcarpeta debe contener al menos los proyectos para las Interfaces de Servicios, y para lasImplementaciones de las Interfaces de Servicios, el proyecto para los Contratos de Datos es

opcional.

x El proyecto de las Interfaces de Servicios para el módulo debe contener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.[Nombre de Módulo], donde:




R [Nombre de Módulo] es el nombre del módulo. Este debe estar en Pascal Case.

x El proyecto de Implementación de las Interfaces de Servicios para el módulo debe contener lasiguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.Impl.[Nombre de Módulo], donde:



R [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.R [Nombre de Módulo] es el nombre del módulo. Este debe estar en Pascal Case.

x El proyecto de Contratos de Datos (opcional) para el módulo debe contener la siguientenomenclatura:[País].[Empresa].[Nombre de Solución].DistributedServices.Contracts.[Nombre de Módulo], donde:


iniciales relevantes y estar en Pascal CaseR [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.R [Nombre de Módulo] es el nombre del módulo. Este debe estar en Pascal Case.

x Puede mantenerse el proyecto de Contrato de Datos en la raíz del proyecto y ser reutilizada por los

distintos proyectos de Interfaces de Servicios de cada módulo.

4.1.4. Capa de Negocio

Esta capa se encargará de recibir, procesar, coordinar las funciones de negocios necesarias para la obtención dela información. Esta capa es relevante debido a que toda la lógica de negocio se debe implementar a este nivel.

�

Capa de Negocio

�

La capa de aplicación contendrá los siguientes proyectos:

x Un proyecto que contiene las clases de negocio, encargadas de coordinar y procesar la información



x Un proyecto que contiene las clases de negocio, encargadas de coordinar y procesar la informacióncon la lógica de negocio definida, el cual debe ser de tipo Librería de Clases.Este proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].Business, donde:



x Un proyecto que contiene los Flujos de trabajo de la aplicación, el cual debe ser de tipo Librería deClases.Este proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].Business.Workflow, donde:



�

4.1.5. Capa de Acceso a Datos

Esta capa contiene las implementaciones que permitirán acceder a los datos y a los servicios externos.

�

Capa Acceso a Datos

�

La capa de Acceso a Datos contendrá los siguientes proyectos:

x Un proyecto de Acceso a Datos Local, el cual debe ser de tipo Librería de Clases.Este proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DataAccess.Data, donde:




x Un proyecto opcional de Agentes de Servicios Externos, el cual debe ser de tipo Librería de Clases.Este proyecto debe tener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DataAccess.ServiceAgent, donde:




En el caso de que se cuente con varios módulos en la solución deberemos usar los siguientes lineamientos:

�

Capa de Acceso a Datos con Módulos

�

x Se deben crear subcarpetas por cada módulo que contenga la solución. Cada subcarpeta debe estar



x Se deben crear subcarpetas por cada módulo que contenga la solución. Cada subcarpeta debe estaren Pascal Case.

x Cada subcarpeta debe contener al menos el proyecto de Acceso a Datos Local para el módulo y

opcionalmente el proyecto de Agentes de Servicios Externos.

x El proyecto de Acceso a Datos Local para el módulo debe contener la siguiente nomenclatura:[País].[Empresa].[Nombre de Solución].DataAccess.Data.[Nombre de Módulo], donde:




R [Nombre de Módulo] es el nombre del módulo. Este debe estar en Pascal Case.

x El proyecto de Agentes de Servicios Externos para el módulo debe contener la siguientenomenclatura:[País].[Empresa].[Nombre de Solución].DataAccess.ServiceAgent.[Nombre de Módulo], donde:



R [Nombre de Solución]�es el nombre de la solución. Este debe estar en Pascal Case.R [Nombre de Módulo] es el nombre del módulo. Este debe estar en Pascal Case.

4.1.6. Recomendaciones de Estructura para la Solución

A continuación describimos algunas recomendaciones de estructura para la solución, de modo que sea másentendible y se pueda trabajar de una forma ordenada, para que se pueda dar soporte en el mantenimiento de laaplicación y el proceso de desarrollo.

Estas recomendaciones están orientadas a la carpeta de las capas lógicas, descritas en la sección anterior, ymantiene la misma organización.

�

4.1.1. Recomendaciones para Aplicaciones Web ASP.NET

En esta sección vamos a listar algunas recomendaciones de estructura para la capa de Presentación,específicamente con una aplicación de tipo Web usando ASP.NET. La Figura ilustra la estructura recomendadapara una aplicación Web con ASP.NET.

Estructura Interna de Aplicación Web con ASP.NET.

�

x La carpeta App_Data contendrá solo las estructuras de datos XML o XSD necesarias para laaplicación Web.

x La carpeta Controllers contendrá todas las clases “Controladoras”. Nos permitirán acceder a las

componentes de negocio o a los servicios.

x La carpeta Extensions contendrá todo el código de extensión que necesitemos y que sea de usoespecífico al proyecto que estamos desarrollando, esto es cualquier código de apoyo necesario para

otras clases del proyecto Web ASP.NET (Utilitarios).



otras clases del proyecto Web ASP.NET (Utilitarios).

x La carpeta Scripts contendrá todos los archivos de recursos de scripting (.js) y los frameworks descripting, como por ejemplo Microsoft.Ajax.js y jquery.js.

x La carpeta Views contendrá todas las Vistas del proyecto (.aspx, html), estas tendrán la estructuraModular, definiendo las vistas principales en la carpeta “Principal”.

x La carpeta UserControls contendrá todos los controles de usuario (.ascx) para funcionalidadestransversales dentro del sitio web estas deberán tener el sufijo “UC”.

x La carpeta App_Themes contendrá todos los recursos relacionados al look&feel del sitio. Para unorden modular se define una carpeta contenedora con el nombre de la empresa con la estructura:

R Images: Contiene imágenes (jpg, png, gif) de negocio o presentaciones varias, ejemplo:botones, animaciones flash, que no tengan incidencia sobre la marca.

R {NombreAplicacion}Controls.skin y {NombreAplicacion}Theme.css: Contiene los skin y

estilos respectivamente definido por aplicativo.

4.1.2. Recomendaciones para Aplicaciones Web ASP.NET MVC

En esta sección vamos a listar algunas recomendaciones de estructura para la capa de Presentación,específicamente con una aplicación de tipo Web usando ASP.NET MVC. La Figura ilustra la estructurarecomendada para una aplicación Web con ASP.NET MVC.

Estructura Interna de Aplicación Web con ASP.NET MVC

�

x La carpeta Content contendrá todos los recursos de estilos (.css) y las imágenes necesarias para laaplicación Web.

x La carpeta Controllers contendrá todas las clases “Controladoras”.

x La carpeta Extensions contendrá todo el código de extensión que necesitemos y que sea de uso

específico al proyecto que estamos desarrollando.R La subcarpeta BootStrapper contendrá cualquier código personalizado necesario para el

inicio de la aplicación Web de ASP.NET (en este caso ASP.NET MVC).

R La subcarpeta ControllerFactories contendrá cualquier clase que implemente el patrón dediseño “Factory” necesario para construir clases “Controladores”. Todas las clases debentener el sufijo Factory.

R La subcarpeta CustomModelBinders contendrá cualquier clase personalizada que permitarealizar los enlaces (bindings), unidireccionales y bidireccionales, de una entidad del dominio,una DTO, ViewModel, o cualquier clase statefull, con las Vistas. Todas las clases deben

tener el sufijo ModelBinder.R La subcarpeta HtmlHelpers contendrá código de extensión de la clase HtmlHelper, que es

parte del Framework de ASP.NET MVC.

R La subcarpeta Utilities contendrá cualquier código de apoyo necesario para otras clases delproyecto Web ASP.NET.

x La carpeta Scripts contendrá todos los archivos de recursos de scripting (.js) y los frameworks descripting, como por ejemplo Microsoft.Ajax.js y jquery.js.

x La carpeta ViewModels contendrá todas las clases de implementen el patrón de diseño“ViewModel” para representar una entidad de dominio en la Vista. Todas las clases debe tener el

sufijo ViewModel.



sufijo ViewModel.

x La carpeta Views contendrá todas las Vistas del proyecto (.aspx y .ascx), estas tendrán la estructuradelineada por ASP.NET MVC, es decir, se tiene que crear una subcarpeta por “Controlador”, la

cual contendrá las Vistas que este “Controlador” maneja.�

4.1.3. Recomendaciones para RIA Silverlight

En esta sección vamos a listar algunas recomendaciones de estructura para la capa de Presentación,específicamente para RIA usando Silverlight. La Figura ilustra la estructura recomendada para RIA con Silverlight.

Figura 12 Estructura Interna de un RIA con Silverlight

�

x Se debe tener un proyecto de Entidades del Dominio que contenga enlaces a las clases de lasEntidades del Domino Real, el cual tiene que estar compilado en Silverlight.

x Se debe tener un proyecto de Agentes de Servicios que consuma los Servicios Distribuidosexpuestos en la Capa de Negocio.

x En el proyecto Cliente se debe tener esta estructura que aplica el patrón de diseño M-V-VM:

R Una carpeta Controls que contenga todos los controles, como los controles de usuario(.xaml), y controles gráficos (.cs) necesarios para este proyecto.

R Una carpeta Resources que contenga todos los recursos gráficos para la aplicación, como

fuentes de letras (.ttf), imágenes (.gif, .jpg, png), y temas (.xaml).R Una carpeta TypeConverters que contenga todas las clases que implementen la interfaz

System.Window.Data.IValueConverter, la cual permite modificar los datos conforme pasas

a través del motor de binding. Las clases deben tener el sufijo Converter.R Una carpeta ViewModels que contenga todas las clases que aplican el patrón de diseño

“ViewModel” para la navegación y control de las vistas y el modelo. Las clases deben tener

el sufijo ViewModel.R Una carpeta Views que contenga todas las Vistas de la aplicación en Silverlight, esta debe

seguir el siguiente lineamiento: Se debe crear una subcarpeta por cada entidad que se maneje

en la aplicación, la cual contendrá todas las Vistas relacionadas a la entidad; la subcarpetadebe tener el sufijo Views, y las Vistas que contiene deben tener el sufijo View.�

4.1.4. Recomendaciones para Aplicaciones de Escritorio Rico con WPF

En esta sección vamos a listar algunas recomendaciones de estructura para la capa de Presentación,específicamente para aplicaciones de Escritorio Rico usando WPF. La Figura ilustra la estructura recomendadapara una aplicación de Escritorio Rico con WPF.

Figura 17 Estructura Interna de una Aplicación de Escritorio Rico con WPF

�

En el proyecto Cliente se debe tener esta estructura que aplica el patrón de diseño M-V-VM:

x Una carpeta Controls que contenga todos los controles, como los controles de usuario (.xaml), y



x Una carpeta Controls que contenga todos los controles, como los controles de usuario (.xaml), ycontroles gráficos (.cs) necesarios para este proyecto.

x Una carpeta Resources que contenga todos los recursos gráficos para la aplicación, como fuentes

de letras (.ttf), imágenes (.gif, .jpg, png), y temas (.xaml).

x Una carpeta TypeConverters que contenga todas las clases que implementen la interfazSystem.Window.Data.IValueConverter, la cual permite modificar los datos conforme pasas a través

del motor de binding. Las clases deben tener el sufijo Converter.

x Una carpeta ViewModels que contenga todas las clases que aplican el patrón de diseño“ViewModel” para la navegación y control de las vistas y el modelo. Las clases deben tener el sufijoViewModel.

x Una carpeta Views que contenga todas las Vistas de la aplicación WPF, esta debe seguir el siguiente

lineamiento: Se debe crear una subcarpeta por cada entidad que se maneje en la aplicación, la cualcontendrá todas las Vistas relacionadas a la entidad; la subcarpeta debe tener el sufijo Views, y lasVistas que contiene deben tener el sufijo View.�

4.1.5. Recomendaciones para el Agente de Servicio Interno (de Presentación)

Como ya se comentó anteriormente, las aplicaciones de Escritorio Rico y, eventualmente, por políticas deseguridad y restricciones de infraestructura física, las aplicaciones Web, requieren conectarse a los ServiciosDistribuidos que se encuentran desplegados en un nivel físico de servidores distinto al donde se encuentra la capade presentación; y esto lo podemos hacer mediante los Agentes de Servicio, los cuales se encapsulan dentro deun proyecto de tipo Librería de Clases que pueda ser reutilizado tanto por la aplicación de Escritorio Rico como laaplicación Web.

�

Figura 18 Estructura Interna del Agente de Servicio de la Capa de Presentación

�

x Una carpeta Service References/Web References que contendrá todos los Proxies hacia losServicios Distribuidos.

x Una carpeta Adapters que contendrá todas las clases que implementen el patrón de diseño“Adapter” para simplemente adaptar la información retornada/enviada de/a los Servicios Distribuidos.Las clases deben tener el sufijo Adapter.

x Una carpeta Converters que contendrá todas las clases que conviertan enteramente el formato de

una entidad, DTO, u otro objeto statefull. Las clases deben tener el sufijo Converter.

�

�

�

�

�

�

4.1.6. Recomendaciones para la Capa de Servicios Distribuidos



En la siguiente Figura se ilustra la estructura interna que deben tener los distintos proyectos de la capa deServicios Distribuidos:

�

Figura 19 Estructura Interna de los Proyectos de la Capa de Servicios Distribuidos

�

x El Proyecto de Interfaces de Servicios, debe contener los siguientes recursos:R Una sola interfaz con el siguiente nombre: I[Nombre de Solución]Service, donde:

� [Nombre de Solución], es el nombre de la solución. Debe estar en Pascal Case.

R Si es que la solución es modular, en otras palabras, que es de un módulo en específico, lainterfaz debe tener la siguiente nomenclatura: I[Nombre de Módulo]Service, donde:� [Nombre de Módulo], es el nombre del módulo. Debe estar en Pascal Case.

R Una carpeta Resources (opcional), que contendrá todos los recursos (.resx) para definir losmensajes de error y mensajes de traza y auditoría, entre otros.

x El Proyecto de Contrato de Datos, debe contener los siguientes recursos:R Una carpeta DTO, que contendrá todos los objetos de transferencia de datos (DTOs).

R Una carpeta Messaging, que contendrá todos los objetos que implementen los contratos demensajes (Message Contract) para definir características más ricas (de seguridad) a lasoperaciones del servicio.


x El Proyecto de Implementación de las Interfaces de Servicios, debe contener los siguientesrecursos:


R Archivos de clase parcial (.cs) que contenga la implementación parcial de las operaciones de

las interfaces de servicio. Deben tener la siguiente nomenclatura: [Nombre deSolución]Service.[Entidad Raíz]Management.cs, donde:� [Nombre de Solución], es el nombre de la solución. Debe estar en Pascal Case.

� [Entitdad Raíz], es la entidad raíz que es gestionada por la capa de Aplicación.R Si es que la solución es modular, en otras palabras, que es de un módulo en específico, la

interfaz debe tener la siguiente nomenclatura: [Nombre de Módulo]Service.[Entidad

Raíz]Management.cs, donde:� [Nombre de Módulo], es el nombre del módulo. Debe estar en Pascal Case.� [Entitdad Raíz], es la entidad raíz que es gestionada por la capa de Aplicación.

x Si es que los Servicios Distribuidos van a ser hospedados en un IIS 6.0 o superior, el Proyecto de

Hosting de los Servicios Distribuidos, debe contener un archivo de servicio (.svc), por cadaInterfaz de Servicio, (tanto de la solución, como de cada módulo). Con el siguiente nombre:[Nombre de Solución]Service.svc, o [Nombre de Módulo]Service.svc, donde:

R [Nombre de Solución], es el nombre de la solución. Debe estar en Pascal Case.R [Nombre de Módulo], es el nombre del módulo. Debe estar en Pascal Case.

4.1.7. Recomendaciones para la Capa de Infraestructura de Persistencia y Acceso aDatos



En la siguiente Figura se ilustra la estructura interna que deben tener los distintos proyectos de la capa deAcceso a Datos:

Figura 22 Estructura Interna de la Capa de Acceso a Datos

�

x El Proyecto de Acceso a Datos, debe contener los siguientes recursos:

R Una carpeta Context, que contendrá el contexto (para Entity Framework) o la clase base deAcceso a Datos (para ADO.NET puro).

R Una carpeta Model, que contendrá el modelo de datos de la aplicación (el modelo entidad-

relación), EDMX (para Entity Framework).R Una carpeta Resources (opcional), que contendrá todos los recursos (.resx) para definir los

mensajes de error y mensajes de traza y auditoría, entre otros.

x El Proyecto de Agentes de Servicios Externos, debe contener los siguiente recursos:

R Una carpeta Service References/Web References que contendrá todos los Proxies hacialos Servicios Distribuidos.

R Una carpeta Adapters que contendrá todas las clases que implementen el patrón de diseño

“Adapter” para simplemente adaptar la información retornada/enviada de/a los ServiciosDistribuidos. Las clases deben tener el sufijo Adapter.

R Una carpeta Converters que contendrá todas las clases que conviertan enteramente el

formato de una entidad, DTO, u otro objeto statefull. Las clases deben tener el sufijoConverter.

R Una carpeta Resources (opcional), que contendrá todos los recursos (.resx) para definir los

mensajes de error y mensajes de traza y auditoría, entre otros.

�

Última modificación realizada el 05/10/2011 12:47 por Arellano Jose Luis

Documents

D01 - Arquitectura “N” Capas