Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 10
 
  Arquitectura de N-Capas y N-Niveles Lo que se conoce como arquitectura en capas es en realidad un estilo de programación donde el objetivo principal es separar los diferentes aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio, mecanismos de almacenamiento, etc.  Los que aprendieron a programar con Pascal, recuerdan que con ese lenguaje todo estaba en la misma porción de código. A lo mejor un progrador cuidadose organizaba las cosas en units , pero al final to
Related documents
Share
Transcript
  Arquitectura de N-Capas y N-Niveles Lo que se conoce como arquitectura en capas es en realidad un estilo de programación donde el objetivo principal esseparar los diferentes aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio,mecanismos de almacenamiento, etc.    Los que aprendieron a programar con Pascal, recuerdan que con ese lenguaje todo estaba en la misma porción decódigo. A lo mejor un progrador cuidadose organizaba las cosas en units , pero al final todo esta amontonado.Vamos a dejar de lado los servicios que el Sistema Operativo facilita para el manejo de archivos, esto esimprescindibleMuchos de nosotros debemos recordar que desde la aparición de los motores de base de datos existen dos niveles perfectamente definidos. Quiero resaltar el uso del término nivel y no el de capa porque no significan lo mismo. Eltérmino capa se utiliza para referenciar a las distintas partes en que una aplicación se dividide desde un punto devista lógico; mientras que nivel corresponde a la forma física en que se organiza una aplicación.    Cuando programaba en COBOL las cosas también se hacian como en Pascal, pero había instalaciones donde sepodía utilizar una Base de Datos y codificar la aplicación con COBOL; de este modo ya teníamos una separación enniveles:Se puede observar con total claridad el nivel de aplicación (seguramente en ella existe código de presentación ylógica de negocio) y el nivel de datos (donde está la o las bases de datos de la organización). El objetivo de esteesquema fue y sigue siendo el de lograr un único repositorio de datos para la organización y múltiples aplicacionesque utilizan esos datos.Ahora consideremos el ejemplo de un componente que permita grabar los programas de televisión emitidos. Estecomponente tiene un sistema de almacenamiento, dado que hace falta guardar las instrucciones sobre el día y horase desea grabar el programa en particular; obviamente existe una porción de lógica de negocio, la que se refiere a lospasos necesarios para capturar el programa de televisión y grabarlo; finalmente hay una interfáz de usuario quepermite a las personas ver y editar las instrucciones de grabación. Podemos decir desde un punto de vista lógico que existentres capas, y hasta que no veamos el código que escribió eldesarrollador vamos a creer que es así. Lo que no se puedenegar es que hay un único nivel, todo esta empotrado enalgún componente de hardware dentro del equipo. Esimportante destacar que hace falta separar el código depresentación del código de lógica de negocio, porque elfabricante puede desarrollar este equipo para que muestrelas instrucciones en un display del mismo equipo o utilizarel televisor; la cuestión es que el código de presentacióntiene que poder intercambiarse, lo cuál es una de lasventajas del desarrollo en capas.  La necesidad de contar con porciones de la aplicación que se puedan intercambiar sin tener que modificar el resto dela aplicación es lo que impulsa el desarrollo en capas; de este modo nos encontramos con el siguiente diagrama:Ahora escribiendo nuevo código podemos intercambiar la capa de presentación sin afectar el resto de la aplicación. Elproblema se presenta cuando queremos intercambiar la Capa / Nivel de Datos, esto significa que necesitamos utilizarotro motor de base de datos y resulta que los fabricantes de motores de bases de datos si bién respetan losestándares, incorporan características valiosas en sus productos. Una aplicación que pretenda utilizar la potencia ocaracterísticas particulares de un motor de base de datos, inevitablemetne incorporará en la Capa de Lógica deNegocios algo de código que no es compatible con otros motores de base de datos. En consecuencia, cambiar la capade datos significa corregir la capa de lógica de negocios.Las buenas prácticas de diseño y desarrollo indican que se debe trabajar sobre el siguiente diagrama: Ahora tenemos 2 niveles y en el primero de ellos diferenciamos 2capas, de esta manera estamos diciendo que la capa de presentacióninteractua con la capa de lógica de negocion; Desde la filosofía dearquitectura en capas, esto significa que la capa de lógica de negociospresenta una interfaz para brindar servicios a la capa depresentación.Del mismo modo, en el diagrama estamos diciendo que existe otronivel donde se encuentra una capa encargada de los datos. Esta capano se muestra como un paquete o ensamblado dado que se trata(generalmente) de un motor de base de datos que puede o noejecutarse en el mismo equipo. Indudablemente esta capa tambiénpresenta una interfaz para brindar sus servicios a la capa que estápor encima.Lo importante y que siempre debemos recordar es que las capasinferiores brindan servicios a las capas superiores(independientemente del nivel en que se encuentren).La clave del desarrollo en capas es que una capa solamente debeutilizar lo que la interfaz de la o las capas inferiores le brindan, deeste modo se puden intercambiar las capas respetando la interfaz ,que viene a ser como un contrato entre capas Ahora si tenemos las tan famosas 3 capas, pero hay que hacer un par deaclaraciones para que nadie se confunda. La nueva capa, se denomina Capa de Acceso a Datos (o Capa de Persistencia)que no es lo mismo que Capa de Datos. La capa de acceso a datos es una porción de código que justamente realiza elacceso a los datos. De esta manera cuando es necesario cambiar el motor debase de datos, solamente tendremos que corregir esa capa.Mientras que la capa de datos (en el nivel de datos) es donde están los datos yse corresponde directamente con la definición de esquemas, tablas, vistas,procedimientos almacenados y todo lo que se pueda o deba poner en un motorde base de datos.   Los arquitectos están felices con este diagrama, sin embargo los desarrolladores tienen un problema. Resulta que loscomponentes de la capa de lógica de negocios necesitan referenciar a instancias de las clases del dominio (las querepresentan las entidades del negocio) y los componentes de la capa de acceso a datos también tienen quereferenciarlas para poder rellenar tales instancias con los datos que obtienen de las capas inferiores.Figura a Figura b Ahora tenemos otra capa más, la capa de Entidades quecorresponde al dominio de la aplicación.En esta capa se encuentra la declaración de las entidadesde la aplicación, de manera que se pueden referenciardesde otras capas sin entrar en ciclos recursivos decompilación.Además este esquema permite una total independenciaentre la lógica de negocios (Business Model) y lasentidades (Domain Model). Por supuesto que ambaspartes están relacionadas por los casos de uso y otrosrequerimientos de la aplicación.Por otro lado, este esquema facilita la incorporación, en lacapa de acceso a datos, de componentes tipo ORM -Objet / Relational Mapping que permiten mapear (representar) objetos en un esquema relacional. Estofunciona bien dado que las bases de datos más utilizadas(por su mejor performance) son las bases de datosrelacionales y no las orientadas a objetos (al menos porahora).La porción de diagrama de la Figura ‘a’ muestra algo queno se debe hacer, porque los componentes no puedencaer en un ciclo de referencias recursivo, no podríacompilarse la aplicación ¿cuál de los dos ensambladosdebe resolverse antes para poder compilar el otro?Una posible solución se presenta en la Figura ‘ b ’ , dondese muestra que la declaración de las Entidades serealiza en la capa de acceso a datos.Bién esto también tiene un problema, la capa de acceso adatos surge porque no queremos tocar la lógica denegocio cuando cambiamos el nivel de datos, y con esteesquema estamos incluyendo en la capa de acceso adatos uno de los aspectos más importantes, que esnuestra definición del dominio de la aplicación; loscambios en la capa de acceso a datos pueden impactar enlas entidades.Para pequeñas aplicaciones esto puede funcionar, inclusose puede poner ambas capas en un único ensamblado condiferentes nombres de espacio (namespace) pero a lalarga traerá problemas.  El nivel de cooperación que presentan las organizaciones requiere que las aplicaciones de software de las distintasorganizaciones interactuen unas con otras. El problema es que algunas de ellas no se ejecutan en la misma plataformao están desarrolladas con marcos de trabajo diferentes. La solución fue presentada como SOA - Service OrientedArchitecture, que brinda entre otras cosas una forma estandard de publicar y utilizar servicios, conocidos comunmentecomo servicios web (web services).
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks