Software y Aplicaciones Web

Blog de desarrollo de software y aplicaciones web

Comentarios Recientes

Comment RSS

MSDN Home Page (Argentina)


C# Corner


AspAlliance.com

Declaración

Las opiniones en este blog se proporcionan "TAL CUAL", sin garantías,  no confieren derechos y no reflejan, necesariamente, la opinión de quienes me contratan.
Algunas cuestiones que se comentan en el blog no son reales, cualquier similitud con alguna persona viva o muerta no es más que una coincidencia, tampoco significa que necesite terapia, soy asi.

© Copyright 2007-2010

Propaganda

Este sitio implementa publicidad basada en intereses
Dec
11.
2008

  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 todo esta amontonado.

 

Vamos a dejar de lado los servicios que el Sistema Operativo facilita para el manejo de archivos, esto es imprescindible.

Figura 1

 

 

Muchos 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. El término capa se utiliza para referenciar a las distintas "partes" en que una aplicación se dividide desde un punto de vista 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 se podía utilizar una Base de Datos y codificar la aplicación con COBOL; de este modo ya teníamos una separación en niveles:

Se puede observar con total claridad el nivel de aplicación (seguramente en ella existe código de presentación y lógica de negocio) y el nivel de datos (donde está la o las bases de datos de la organización). El objetivo de este esquema fue y sigue siendo el de lograr un único repositorio de datos para la organización y múltiples aplicaciones que utilizan esos datos.

Figura 2

 

Ahora consideremos el ejemplo de un componente que permita grabar los programas de televisión emitidos. Este componente tiene un sistema de almacenamiento, dado que hace falta "guardar" las instrucciones sobre el día y hora se desea grabar el programa en particular; obviamente existe una porción de lógica de negocio, la que se refiere a los pasos necesarios para capturar el programa de televisión y grabarlo; finalmente hay una interfáz de usuario que permite a las personas ver y editar las instrucciones de grabación.

Podemos decir desde un punto de vista lógico que existen tres capas, y hasta que no veamos el código que escribió el desarrollador vamos a creer que es así.

Lo que no se puede negar es que hay un único nivel, todo esta empotrado en algún componente de hardware dentro del equipo.

Es importante destacar que hace falta separar el código de presentación del código de lógica de negocio, porque el fabricante puede desarrollar este equipo para que muestre las instrucciones en un display del mismo equipo o utilizar el televisor; la cuestión es que el código de presentación tiene que poder intercambiarse, lo cuál es una de las ventajas del desarrollo en capas.

Figura 3

 


La necesidad de contar con porciones de la aplicación que se puedan "intercambiar" sin tener que modificar el resto de la aplicación es lo que impulsa el desarrollo en capas; de este modo nos encontramos con el siguiente diagrama:

Figura 4

Ahora tenemos 2 niveles y en el primero de ellos diferenciamos 2 capas, de esta manera estamos diciendo que la capa de presentación interactua con la capa de lógica de negocion; Desde la filosofía de arquitectura en capas, esto significa que la capa de lógica de negocios presenta una "interfaz" para brindar servicios a la capa de presentación.

Del mismo modo, en el diagrama estamos diciendo que existe otro nivel donde se encuentra una capa encargada de los datos. Esta capa no se muestra como un "paquete" o "ensamblado" dado que se trata (generalmente) de un motor de base de datos que puede o no ejecutarse en el mismo equipo. Indudablemente esta capa también presenta una "interfaz" para brindar sus servicios a la capa que está por encima.

Lo importante y que siempre debemos recordar es que las capas inferiores brindan servicios a las capas superiores (independientemente del nivel en que se encuentren).

La clave del desarrollo en capas es que una capa solamente debe utilizar lo que la "interfaz" de la o las capas inferiores le brindan, de este modo se puden intercambiar las capas respetando la "interfaz", que viene a ser como un "contrato entre capas"

Ahora escribiendo nuevo código podemos intercambiar la capa de presentación sin afectar el resto de la aplicación. El problema se presenta cuando queremos intercambiar la Capa / Nivel de Datos, esto significa que necesitamos utilizar otro motor de base de datos y resulta que los fabricantes de motores de bases de datos si bién respetan los estándares, incorporan características valiosas en sus productos. Una aplicación que pretenda utilizar la "potencia" o características particulares de un motor de base de datos, inevitablemetne incorporará en la Capa de Lógica de Negocios algo de código que no es compatible con otros motores de base de datos. En consecuencia, cambiar la capa de 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:

Figura 5

Ahora si tenemos las tan famosas 3 capas, pero hay que hacer un par de aclaraciones 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 el acceso a los datos. De esta manera cuando es necesario cambiar el motor de base 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 y se corresponde directamente con la definición de esquemas, tablas, vistas, procedimientos almacenadaos y todo lo que se pueda o deba poner en un motor de base de datos.

 


 

Los arquitectos están felices con este diagrama, sin embargo los desarrolladores tienen un problema. Resulta que los componentes de la capa de lógica de negocios necesitan referenciar a instancias de las "clases del dominio" (las que representan las entidades del negocio) y los componentes de la capa de acceso a datos también tienen que referenciarlas para poder "rellenar" tales instancias con los datos que obtienen de las capas inferiores.

 

Figura 6 (a)                                    Figura 6 (b)

La porción de diagrama de la Figura 6 (a) muestra algo que no se debe hacer, porque los componentes no pueden caer en un ciclo de referencias recursivo,  no podría compilarse la aplicación ¿cuál de los dos ensamblados debe resolverse antes para poder compilar el otro?

Una posible solución se presenta en la Figura 6 (b), donde se muestra que la declaración de las "Entidades" se realiza en la capa de acceso a datos.

Bién esto también tiene un problema, la capa de acceso a datos surge porque no queremos "tocar" la lógica de negocio cuando cambiamos el nivel de datos, y con este esquema estamos incluyendo en la capa de acceso a datos uno de los aspectos más importantes, que es nuestra definición del dominio de la aplicación; los cambios en la capa de acceso a datos pueden impactar en las entidades.

Para pequeñas aplicaciones esto puede funcionar, incluso se puede poner ambas capas en un único ensamblado con diferentes nombres de espacio (namespace) pero a la larga traerá problemas. 

 

La solución que satisface a los arquitectos y a los desarrolladores, es la siguiente:

Figura 7

Ahora tenemos otra capa más, la capa de Entidades que corresponde al dominio de la aplicación.

En esta capa se encuentra la declaración de las entidades de la aplicación, de manera que se pueden referenciar desde otras capas sin entrar en ciclos recursivos de compilación.

Además este esquema permite una total independencia entre la lógica de negocios (Business Model) y las entidades (Domain Model). Por supuesto que ambas partes están relacionadas por los casos de uso y otros requerimientos de la aplicación.

Por otro lado, este esquema facilita la incorporación, en la capa de acceso a datos, de componentes tipo ORM - Objet / Relational Mapping que permiten "mapear" (representar) objetos en un esquema relacional. Esto funciona bién dado que las bases de datos más  utilizadas (por su mejor performance) son las bases de datos relacionales y no las orientadas a objetos (al menos por ahora).

 


 

El nivel de cooperación que presentan las organizaciones requiere que las aplicaciones de software de las distintas organizaciones interactuen unas con otras. El problema es que algunas de ellas no se ejecutan en la misma plataforma o están desarrolladas con marcos de trabajo diferentes. La solución fue presentada como SOA - Service Oriented Architecture, que brinda entre otras cosas una forma estandard de publicar y utilizar servicios, conocidos comunmente como servicios web (web services).

Figura 8

La Figura 8 muestra como los usuarios finales, mediante la utilización de hardware o software liviano, pueden acceder a lo que se denomina el nivel de clientes o aplicaciones que básicamente se constituyen de la capa de presentación y consumen los servicios publicados por la misma organización. Este tipo de aplicaciones son en general sitios o portales en la web.

Pueden implementarse soluciones del tipo cliente - servidor en donde el usuario final accede de manera directa a una aplicación de escritorio que consume los servicios publicados al igual que las aplicaciones para hardware y/o software liviano.

Aplicaciones de otras organizaciones también pueden utilizar los servicios publicados por una organización en particular, obviamente esto necesita de acuerdos comerciales y credenciales para autenticar y autorizar a quienes consumen los servicios.


 

 

La pregunta ahora es: ¿Los servicios publicados forman parte de la capa de lógica de negocio?

En algunos caso, como por ejemplo recuperar la información de un inmueble podemos decir que el servicio en si mismo no presenta lógica alguna.

En otros casos, como por ejemplo pagar la factura de un servicio público desde la cuenta bancaria del usuario final si presenta un nivel de lógica que no tiene que ver con la lógica del negocio (sea de la institución pública o del banco). Se trata de la lógica de la transacción que involucra dos organizaciones diferentes (aplicaciones diferentes), consecuentemente debe existir un mecanismo que permita confirmar la realización de todos los "pasos" que cada una de las organizaciones requiere; esto normalmente se conoce como WorkFlow.

De esta manera surje otra capa más, la capa de Servicios Publicados que pueden o no incluir componentes de WorkFlow pero inevitablemente deben estar por arriba de la capa de lógica de negocios. La Figura 9 muestra el diagrama completo incluso con el componente escencial de la aplicación: el Esquema de Seguridad, así como la línea de vida de las entidades en relación a las distintas capas.

 

Figura 9

 

Espero que mis consideraciones les sirvan y por supuesto estoy dispuesto a debatir otras opiniones. 

 




Categorías: Programacion | WebSite



Comments (39) -

Pablo Argentina

Saturday, December 27, 2008 10:54 AM

Pablo

Muy buenos ejemplos y detalles.

cristian

Thursday, February 19, 2009 8:16 PM

cristian

Gracias por el articulo!... me ayudo a afianzar varios conceptos.

Yunier

Thursday, April 30, 2009 3:15 AM

Yunier

amigo el artículo está muy bueno, necesito saber como puedo justificar la utilización de la arquitectura
en capas y no de otra arquitectura para el siguiente caso: si tengo una misma aplicación publicada en dos
servidores, donde en un servidor se publicará la aplicaión así como los métodos del negocio de la aplicaión,
q serán consumidos por la aplicación publicada en el otro servidor.

Gracias de antemano.

jtentor Argentina

Thursday, April 30, 2009 9:27 AM

jtentor

La justificación arranca por el solo hecho que hay dos servidores con la misma aplicción, es inaceptable llevar el mantenimiento por separado de ambas instalaciones. En consecuencia la arquitectura de la "la aplicación" es en capas, las que podrían ser: datos, lógica, servicios, Interfaz 1, Interfaz 2. De este modo las interfaces consumen los servicios provistos; un buen esquema para ello es el de la figura 9, sin embargo puede considerarse que una de las interfaces acceda directamente a la lógica mientras que la otra lo haga por medio de servicios web, pero esto puede llevar a desarrollar entidades separadas para hacer lo mismo. Me parece que hay que realizar un análisis de conveniencia sobre esta alternativa contra una en la que ambas interfaces consuman servicios web. Esto último me parece mejor porque si hacen falta dos interfaces es porque hay algún aspecto del usuario final que así lo requiere, por lo tanto el soporte para cada interfaz podrá ser diferente e independiente del resto de la aplicación.
Espero que sirva.

Yunier

Thursday, April 30, 2009 9:54 AM

Yunier

ok, muchas gracias.

Yunier

Wednesday, May 06, 2009 12:13 PM

Yunier

amigo estuve leyendo un artículo (del cual obtuve algo de información para la tesis) y me surgió
una duda en un fragmento del artículo:

en el articulo se refiere a: "la estructura en capas se ha constituido en un estándar a la hora de
desarrollar aplicaciones distribuidas para sistemas empresariales dejando obsoleto el clásico
modelo cliente-servidor".

Sin embargo, la distribución de capas lógicas en diferentes capas físicas constituye en gran medida
un caso particular de la arquitectura cliente/servidor. ¿Cómo se puede explicar esta aparente "contradicción"?

jtentor Argentina

Thursday, May 07, 2009 12:39 AM

jtentor

La arquitectura cliente-servidor se conoce también como arquitectura de dos capas, consecuentemente cualquier arquitectura de N-capas es una evolución de ella. Actualmente las aplicaciones tiene la forma de sitios o portales en la web (aún cuando se utilicen solo en una intranet), antes de la WWW lo que teníamos eran aplicaciones (clientes) que se distribuían en las máquinas de todos los usuarios y por medio de la red accedían a una base de datos común (servidor); desde mi punto de vista eso era una arquitectura de dos niveles: interfaz + lógica en la aplicación del lado del cliente (1er nivel) y capa de datos del lado del servidor (2do nivel). Ese 1er nivel puede haber estado o no dividido en capas.

Es cierto que el modelo cliente-servidor es obsoleto dado que mantener cientos de máquinas actualizadas con la última verisón de la aplicación es un problema, es mucho mejor que los usuarios utilicen un cliente liviano (browser) para acceder a un sito o portal, solamente hay que mantener ese sitio o portal. Sin embargo no es la estructura en capas la que deja obsoleta el modelo, existen aplicaciones cliente-servidor construidas en capas; lo que deja obsoleto al modelo es la complejidad de su mantenimiento.

La arquitectura en capas (y niveles) de hecho es cliente-servidor donde cada capa solicita un servicio de la capa inferior, esto facilita el intercambio de capas sin tener que modificar toda la arquitectura. De manera que decir que ese modelo está obsoleto es una equivocación de conceptos; lo que si se puede afirmar es que el clásico modelo cliente-servidor es el ejemplo más sencillo de una arquitectura en capas y niveles, en particular en dos niveles.

Yo diría que la distribuciíon de capas lógicas en diferentes capas fisicas consituye el caso general de la arquitectura cliente-servidor, la cual se inció con dos niveles y actualemente presenta N-niveles y N-capas.

Saludos.

sofia Peru

Thursday, June 11, 2009 3:49 AM

sofia

mas que un comentario mira ami me enseeñaron que tres capas solo era la presentcion , logica de negocio y accesoa detaso pero nunca me hablaron de la capa de persistencia de datos, ademas dime que opinas de que si una aplicacion esta dividida en tres capas  pero alcolocar las dos primeras capas en una sola maquina ya se trat de un cliente servidor y de dos capas es correcto esto.
que opinas del modelo mvc es una buena arquitectura , tres cpas es aplicable para cualquier lenguaje de programacion por ejemplo php

jtentor Argentina

Thursday, June 11, 2009 4:30 AM

jtentor

Cierto, cuando se enseña se indica que tres capas significa presentación, lógica y acceso a datos. Es lo que presenta la figura 4, además en esa figura se marca la posibilidad que la capa de datos se encuentre en otro equipo de manera que también se conoce como cliente-servidor. Recordemos que capa es un concepto lógico y nivel es un concepto físico; cliente-servidor puede ser de dos capas: la que esta en el servidor que es la de acceso a datos y la que que está en el cliente que tendrá codigo de presentación y de lógica, ahora si esa parte (la del cliente) se divide en dos capas para diferenciar el código de presentación con el código de lógica de negocio entonces tenemos cliente-servidor y tres capas.
El termino "persistencia" es muy frecuente entre  los desarrolladores que utilizan Java mientras que "acceso a datos" es más utilizando por otros desarrolladores; sin embargo ámbos representan el componente de software que facilita el acceso a los datos.
El modelo MVC ha tomando mucha "fuerza" en los últimos años gracias a la publicación de frameworks que obligan a desarrollar las aplicaciones al menos en tres capas: Model, View, Controller. Obviamente al incorporar la capa de vista (view) se trata de un modelo para usuarios finales, sin embargo no es aplicable si vamos a desarrollar una aplicación que publique servicios web para que otras aplicaciones las consuman y entonces debemos armar nuestra propia arquitectura.
PHP cuenta con buenos marcos de trabajo orientados al modelo MVC por ejemplo http://www.symfony-project.org/.

Hernan Argentina

Saturday, June 20, 2009 3:50 AM

Hernan

Hola Julio, un gusto escribirte, estoy desarrollando un e-commerce de venta de libros, más conocido
simplemente como "carrito de compras". Dentro de la "arquitectura base" estoy planteando la
"descripción de las capas lógicas y servicios". El sistema debe soportar seguridad, errores, idioma,
bitácora y persistencia. Lo que hice es: UI->BLL->DAL. La pregunta es, ¿dónde y como incluír
seguridad, errores, idioma, bitácora y persistencia?. Muchas gracias!.

jtentor Argentina

Saturday, June 20, 2009 10:51 PM

jtentor

Hernan, los aspectos de seguridad, errores, idioma, etc. forman parte de la funcionalidad exigida al producto de software; no constituyen una capa o nivel desde el punto de vista arquitectónico, se trata de "modulos" y en consecuencia dependiendo de su naturaleza pueden organizarse en capas (concepto lógico) y/o en nivel (concepto físico).

Seguridad, se trata de usuarios y grupos (roles o funciones) que requiere una interfaz de usuario para login, administración de usuarios y grupos, obviamente existe cierta lógica los usuarios una véz autenticados deben pasar por los filtros de acceso (no todos pueden hacer de todo en la aplicación) y finalmente requiere de un almacenamiento de manera que tambíen presenta componente en la capa de acceso a datos.

Errores, se debe controlar capturando las excepciones y actuando en consecuencia; en general lo que debe hacerse es avisar que ha ocurrido un error y no pudo realizarse la operación. De hecho no lo considero una funcionalidad, sino un requisito propio del desarrollo de software. Siempre se debe controlar los errores puede ser que la base de datos no esté en línea entonces el primer intento de conectarse provocara un error que debe ser interceptado y avisarle al usuario que está ocurriendo.

Idioma, indudablemente cae en todo lo que es interfáz de usuario; sin embargo puede ser que ciertos mensajes tengan su origen en alguna "capa" inferior de modo que se posible incorporar alguna gestión de idiomas en estas capas. Actualmente todos los entornos de ejecución pueden detectar el idioma del cliente (browser) y de acuerdo a eso presentar la interfaz de usuario adecuadamente, para ello hace falta un mecanismo automático de selección de textos y por supuesto una forma de guardarlos; algunos entornos son más faciles que otros pero en generál hacen lo mismo.

Bitacora, para esto hay componentes disponibles para todas las plataformas que son totalmente configurables y pueden registrar en un "log" todo lo que ocurre; quíen ingresa, cuando lo hace, que hace, de todo.

Persistencia, es la capa de acceso a datos y para ello hay productos como Hibernate que facilitan la independencia total del motor de base de datos.

Repito, todo esto es "funcionalidad" puede ir en alguna o todas las capas de tu arquitectura. Otra cosa sería que esta aplicación deba publicar el ranking de libros más vendidos de manera que otras aplicaciones puedan acceder a esa información y mostrarla, en este caso se debe implementar un servicio web o simplemente un RSS, y en este caso se agrega una "capa" que es la de servicios (no interactua con usuarios sino con aplicaciones).

Espero que sirva.

Alex Spain

Sunday, January 03, 2010 6:12 AM

Alex

Hola Julio, acabo de leer este artículo y me parece muy interesante, al igual que todo el blog en conjunto.

Actualmente estoy preparando un examen enfocado desde la perspectiva de las tecnologías .NET, y tengo varias dudas respecto a a la distribución en capas/niveles de una aplicación en relación al empleo de servicios web.

En primer lugar, creo entender que los servicios web normalmente son empleados tanto desde la capa de lógica de aplicación, como desde la capa de presentación (o desde cualquier capa en la cual sea necesario). Su uso, si no me equivoco dependerá de las necesidades de cada una de las capas. Por ejemplo, si realizo una llamada a un servicio web que devuelve un listado de productos que van a ser mostrados en el navegador, la llamada a dicho servicio web sería realizada desde la capa de presentación. En cambio, si por ejemplo la aplicación ha de comprobar ciertos índices económicos para ajustar los precios de ciertos productos, y dichos índices son devueltos por un servicio web, en este caso la llamada será realizada desde la capa de lógica de negocio; ya que aún habrá que realizar el ajuste de precios en función de los índices obtenidos. ¿Estoy en lo cierto?

Por otro lado, dispongo de un listado de preguntas tipo examen, y no se muy bien como enfocar una de ellas, que trata sobre el tema al que hace referencia este artículo. La pregunta es la siguiente:

"Explica cuáles son las ventajas de trabajar con una aplicación de tres capas (presentación, lógica de negocio y persistencia) cuando se desarrolla una aplicación que utiliza un servicio Web". (las ventajas de emplear una aplicación particionada en capas son evidentes, pero hay que realizar un enfoque en lo que respecto a dicha estructura en el caso del empleo se servicios web)

En un principio tan sólo se me ocurre la siguente ventaja:

1. Mejor redistribución del tráfico de datos de la aplicación, suponiendo que cada una de las capas se ejecute en un nivel diferente.

No se si estoy olvidando algún detalle respecto a temas de seguridad o respecto a algún otro aspecto relativo al empleo de servicios web.

¿Se te ocurre algo que se me esté escapando?

Saludos!




jtentor Argentina

Sunday, January 03, 2010 12:05 PM

jtentor

Alex, gracias por tus comentarios y aporte. Puedo agregar lo siguiente:

Efectivamente los servicios web se pueden consumir desde cualquier capa, por supuesto hay que tener en mente que un servicio web tiene un proposito que probablemente indique donde debe consumirse. Por ejemplo en la capa de acceso a datos puede enmascarse detrás de un clase que brinde "datos" a una aplicacion el consumo y manipulación de esos datos mediante un servicio web. Otro ejemplo es lo que está ocurriendo con Silverlight, que es un imponente marco de trabajo para la interfaz de usuario que realiza la lógica y el acceso a datos mediante servicios web, de este modo se puede convertir con facilidad viejas aplicaciones en las conocidas RIA (Aplicaciones ricas de Internet)

Como ventaja de trabajar en capas y/o niveles me parece más importante la escalabilidad del producto el futuro mantenimiento y extensión o ampliación del mismo. Imaginemos una organización que comienza con un portal de comercio electronico y luego, al crecer dedice asociar a sus clientes como revendedores de sus productos; indudablemente estos clientes deberían tener un acceso al sistema más agil que el portal estandard de comercio electrónico. Es ahí donde una aplicación desarrollada en capas (ensamblados) y niveles (dferentes equipos) cobra mucha importancia dado que la parte del producto que utiliza el portal estandard de comercio electrónico utiliza una lógica y un acceso a datos determinado, que puede reutilizarse y/o ampliarse para aquella parte del producto de software que necesitarán los revendoderes cambiando algunas partes de la interfaz de usuario por servicios web que dichos revendedores pueden consumir directamente desde sus propias aplicaciones.

Como desventaja, estoy de acuerdo en que un proyecto planeado en capas y niveles implica más código; en general las herramientas actuales (Visual Studio) generan código listo para usar pero todo en una sola clase e incluso embebido en la misma interfáz de usuarios. No quiero decir que esto esté mal, lo que ocurre es que hay que analizar el producto y su futuro para tomar decisiones sobre la arquitectura del mismo y por supuesto es el cliente quién decide si va a pagar un poco más para desarrollar un producto escalable de facil mantenimiento y expansión o en el futuro cuando desea cambiar haya que volver a desarrollar cosas que ya están hechas pero no se pueden utilizar dado que el código esta todo mezclado y el costo de introducir cambios es mayor.

En particular yo veo lo de seguridad como un módulo vertical entre las capas y niveles, con lo que quiero decir que esta parte de toda aplicación debe estar presente en todas las capas y niveles, sin embargo no debe olvidarse que al respecto los sistemas operativos actuales han avanzando muchísimo y las aplicaciones deberían utilizar esos servicios de seguridad, el problema se presenta cuando se trata de aplicaciones multiplataforma pero en este caso estamos hablando de grandes desarrollos y seguramente se puede cubrir los costos de semejante desarrollo.

Finalmente conincido contigo en que la mejor distribución del trafico de datos es una ventaja, especialmente cuando se trata de aplicaciones que requieren mucho acceso a datos; el poder utilizar un servidor dedicado solamante al motor de base de datos permite utilizar una granja de servidores para atender a miles - millones de usuarios y cuando el motor de base de datos te queda chico, se amplia a una base de datos distribuída cambiando solamente un nivel de toda la aplicación. Pero obsevemos que nuevamente estamos hablando de escalabilidad, mantenimiento, expansión.

Espero que sirva. Saludos.

Alex Spain

Sunday, January 03, 2010 6:51 PM

Alex

Excelente y completa respuesta!, muchas gracias!

Tu blog a pasado a ser uno de mis favoritos rapidamente.

Saludos!.

Jose Ecuador

Tuesday, January 05, 2010 5:43 PM

Jose

Hola saludos desde Quito, quiero agradecerte por el excelente articulo que has hecho, quiero hacerte una pregunta con respecto a los servicios web y la logica de negocio, estas dos capas deben estar necesariamentes en el mismo nivel o si se pueden dividir en dos niveles ?. si la respuestas es no y si, por favor podrias decirme como hago esto?, ya que la logica de negocio vendria hacer una dll, como referencio a mi servico web ya en implementacion?

Gracias de antemano.

jtentor Argentina

Thursday, January 21, 2010 12:01 PM

jtentor

Jose, los servicios web por su escencia son otra capa y de hecho otro nivel (funcionan en otro equipo, salvo en el momento de desarrollo que lo hacemos todo en una sola maquina). La lógica de negocio puede estar detras, en otra capa o en el medio del servicio web en el caso que el servicio sea algo complejo como por ejemplo lo que te permite utilizar paypal o las tarjetas de crédido; ellos publican un servicio al que se accede desede cualquier página, pero el proceso se realiza detras del servicio. Otra posibilidad es que una organización acuerdo con su proveedor un servicios de ordenes de compra, en este caso el proveedor publica el servicio y la organización utiliza su propia lógica para armar las ordenes de compra que se envian el servicio web, lo que desencadenará un envío, remito y posterior factura. De manera que la lógica puede estar o no junto al servicio eso se debe evaluar de acuerdo a la aplicación y al tamaño (escala) de la aplicación.
Respecto a los dll, cuando se arma un servicio web inevitablemente hay que publicarlo por separado, consecuentemente es otro dll, ahora este servicio puede o no tener varios proyectos dentro de la solución y entonces contaría con varias dll. Fijate los ejemplos que están en www.jtentor.com.ar/.../...cation-Foundation-1.aspx
Espero que te sirva.

carlos Bolivia

Saturday, November 26, 2011 12:02 AM

carlos

Super
bastatne interesante este articulo

OscarM Colombia

Wednesday, December 14, 2011 12:12 AM

OscarM

Muchas gracias por esas explicaciones tan bien construidas, porque indudablemente permiten que todos aquellos que estamos en ese camino del aprendizaje nos ayude.
Gracias.

carlos Peru

Tuesday, December 27, 2011 11:59 AM

carlos

Muy interesante la informacion que brindas,quisiera hacer una consulta tengo un proyecto que esta estructurado en capas capas en preseetacion ,entidad,negocio,datos...y tengo aumentarle seguridad ami proyecto y eh estado investigando y eh encontrado sobre la capa de seguridad pero no tengo idea como implementar esta capa..porfavor me podrian dar luces acerca del tema..gracias de antemano.

jtentor Spain

Tuesday, December 27, 2011 12:22 PM

jtentor

Carlos, lo primero que tenemos que tener en cuenta es que una "capa" no es lo mismo que una "funcionalidad" que el producto de software brinda. Por ejemplo un carro de compra en un sitio de comercio electrónico es una "funcionalidad" que el cliente pide; esa funcionalidad se puede implementar monoliticamente o en capas, es decir una capa o porción de software que contiene los elementos de la interfaz de usuario (grilla de artículos, botones para cancelar, agregar, pagar, etc), otra capa que contiene la lógica (calcular totales, verificar stock, aplicar descuentos, etc) y seguramente otra capa de acceso a los datos (objetos que presentan los datos en algún formato, obviamente los traen de algún lado).
En el caso de seguridad, esta mal expresado pensar que hay una "capa de seguridad" en realidad es una "funcionalidad" del producto de software y como tal se implementa en diferentes capas. Por ejemplo para que un usuario pueda hacer el login en la aplicación, hace falta un componente de interfaz de usuario que muestre al menos los dos campos "nombre de usuario" y "password" el boton de aceptar y el de cancelar; opcionalmente pueden estar los botones para "olvide el password", "registrarse", "ayuda", y otras cosas que se nos ocurre. Como dije eso va en la capa de presentación que podría ser Silverlight o Windows Forms; luego por debajo de esta capa debe existir una capa de lógica que es la que valida los datos ingresados y solicita a la capa de acceso a datos busque la información en la base de datos. El último diagrama de este post muestra cómo sería.
Lo que ocurre es que en general se utiliza algún componente echo que nos brinda la funcionalidad, en el caso de .NET ese componente es el Membership Provider, que tiene todos los componentes que necesitas para la interfaz de usuario, ademas tiene las clases de lógica y persistencia necesarias. También podrías ver las Bussiness Applications con Silverlight 4 o superior te facilitan lo mismo pero con Silverlight.
Implementar seguridad en un proyecto, no significa crear usuarios y permitir que hagan login. La cuestión es que se debe definir los roles o grupos de usuarios y luego definir que partes de la aplicación pueden ser accedidas por integrantes de estos grupos, finalmente se organizan estos componentes en carpetas (directorios) y se restringe el acceso a dichas carpetas para los usuarios que no son de los grupos habilitados. Esto se hace en archivos web.config que están en cada directorio con las opciones que te permite el administrador de usuarios y grupos en el Visual Studio.
Creo que en http://anotherblog.codeplex.com/ hay un buen ejemplo de cómo se puede hacer.
Espero que te sirva.

carlos Peru

Sunday, January 15, 2012 3:14 PM

carlos

Holas gracias por la información..,,,muy buena.Tengo otra consulta cual seria el tipo
la infraestructura necesaria para un modelo que contiene presentación,negocio,data y entidad puesto que la aplicación que se esta realizando esta en asp.net. ,actualmente me informaron que deberia ser cliente y servidor..pero quisiera saber si no hay otra alternativa de infraestructura.gracias por su respuesta.

jtentor Argentina

Monday, January 23, 2012 6:34 PM

jtentor

Carlos, la infraestructura es lo que se conoce como un "requisito no funcional". A mi me gusta la denominación "atributo de calidad del software"; dado que es el cliente el que tiene que indicar el nivel de accesibilidad que la aplicación debe tener; esto define si se puede o no utilizar internet o al menos define los niveles de seguridad que la aplicación tendrá. Por otro lado si el cliente dice que deben incorporarse cambios en no más de una hora de haberse aprobado, entonces una aplicación cliente-servidor puede ser complicada de mantener (hay que cambiar el software cliente en todas las máquinas y nunca se sabe si una maquina quedo sin actualizar, lo que implica un desarrollo con verificación de versiones y releases; en cuyo caso sería mejor una aplicación web donde solo se cambia los componentes del servidor web y a partir de ese momento todos los que ingresan lo hacen con la nueva versión).
Una aplicación web aunque funcione en un servidior web dentro de la red privada de la organizacón (sin internet) resulta más facil de mantener pero no es tan atractiva como una aplicación de escritorio (cliente-servidor); actualmente se puede usar Silverlight y también HTML5 lo que te permite lograr mejores presentaciones pero eso requiere de mejores equipos para acceder al sitio y de un razonable ancho de banda (si es una red local todo anda bien, pero en internet a veceds es lenta)

En general se considera que las aplicaciones Cliente-Servidior son aquellas en las que el código "cliente" contienen lo que yo denomino capa de presentación, capa de lógica de negocios y capa de acceso a datos; mientras que el código "servidor" resulta ser un motor de base de datos puesto en alguna máquina; incluso he visto que la base de datos solo tiene tablas y una que otra relación, todo se hace mediante código SQL incrustado en porciones de código en lo que llaman "cliente".

Desde mi punto de vista cuando una aplicación cuenta con dos "niveles" ya es considerada Cliente-Servidor, recordá que "nivel" se utiliza para indicar que corren en equipos distintos o al menos en entornos de ejecución diferentes.

Si tu aplicación tiene bien dividida la capa de presentación de las otras, es posible que puedas desarrollar (si te lo pagan) varias infraestructuras, una con windows-form (cliente servidior) otra web-application con un portar de intranet o internet.

De todos modos te recomiendo charlar con el cliente para definir que quiere hoy y que piensa que va a necesitar dentro de 6 o 12 meses de manera que se pueda plantear un producto de software que evolucione sin complicaciones.

Cristian Argentina

Thursday, February 02, 2012 5:23 PM

Cristian

Felicitaciones por el blog! Este articulo me saco muchas dudas a la hora de trabajar en capas, como bien se dice en un comentario cuando nos enseñan el trabajar en capas, solo mencionan las la de presentación, la de negocios y la de datos.  :-D y en el momento de ponerlo en práctica, topas con otra realidad. Gracias.

Miriam Gomez Mexico

Thursday, September 27, 2012 6:27 PM

Miriam Gomez

Hola soy Miriam desde México. Muy bien explicado tu articulo.. gracias!!!

rekuplex Peru

Friday, September 28, 2012 5:08 AM

rekuplex

muchisimas gracias por el articulo, muy bien explicado cada concepto.

Kleyvert Venezuela

Friday, October 26, 2012 4:32 PM

Kleyvert

Hola buenas, excelente articulo, explica muy bien el concepto de la arquitectura en capas, saludos desde Caracas, Venezuela!

Rodrigo Santamaria Colombia

Monday, November 05, 2012 12:30 AM

Rodrigo Santamaria

Buenas noches.   Gracias por todo el esfuerzo, no solo por el articulo tan interesante, si no por el empeño que le ponen al responder las preguntas.   Gracias de verdad.  

Allan Honduras

Friday, November 16, 2012 1:03 AM

Allan

Muy buen publicación!

Mariam Caribbean

Friday, February 01, 2013 4:24 AM

Mariam

me encanto el articulo , no lo habia podido entender hasta ahora, graciasªª

Ary Spain

Tuesday, March 05, 2013 3:31 PM

Ary

Hola, estoy trabajando en un aplicación, que tiene como objetivo el desarrollo de un compilador a bytecodes, he separado la logica de funcionamiento en dos módulos, uno para realizar la fase de análisis(chequeo léxico, sintáctico y semántico) y otro para realizar la fase de síntesis(generación de código intermedio y optimización), mi pregunta es la siguiente, puedo afirmar que estoy utilizando una arquitectura en N capas??

jtentor Spain

Tuesday, March 05, 2013 4:34 PM

jtentor

Ary, si se puede afirmar que es una arquitectura en capas.

Particularmente se puede decir que hay dos capas una para el análisis y la otra para la síntesis. Esta última capa podria incluso separarse en subcapas una para la generación de código intermedio y la otra para la optimización.

La escencia de las capas es que presentan una interfaz con otra capa de modo que la comunicación o colaboración se realiza por medio de esa interfaz, que se supone es conocida o publicada y no va a cambiar. En el futuro es posible cambiar la capa respetando la interfaz.

Si el compilador que estas desarrollando tuviese como destino el código ensamblador de algún microprocesador, podría tener una capa que genera código para procesadores intel y lo optimiza bajo algún criterio; en otro momento esa capa podría cambiarse por un generador de código RISC también optimizado bajo algún criterio.

Es más en el futuro podría realizarse una configuración que permita al usuario, mediante un archivo de configuración o una selección en tiempo de ejecución, definir el tipo de código a generar y de este modo el compilador generaría código con uno u otro módulo pero la fase de análisis lexico, sintáctico y semántico sería la misma.

En este caso el destino de tu compilador son bytecodes, pero podría ser el lenguaje intermedio de ejecución de la plataforma .NET y entonces.

Espero que te sirva.


Rodrigo Santamaria Colombia

Thursday, March 07, 2013 11:38 AM

Rodrigo Santamaria

Buenos dias Julio.

Nuevamente muchas gracias por el articulo y por responder estas preguntas.

Estoy organizando un grupo de trabajo, tengo dos ingenieros, y un diseñador web. entonces pesnse en poner un ingeniero en la capa de negocio y otro en la capa de datos, y que el diseñador desarolle el UI, pero surgio una controversia que espero nos ayudes a solucionar. Ya decidimos que la primer capa que desarrollaremos es la UI, entonces que es lo logico, que a partir de toda la informacion recogida y con la interfaz desarrollada y aprobada por el usuario, se continue con la capa de datos, o con la de negocio?.

Para mi, como se empezo con la interfaz, despues se debe contruir la logica del negocio y realizar un documento donde se solicite al otro ingeniero que queremos que nos proovea la Base de datos.

Para el otro Ing es:  que despues de tener la interfaz, se realiza la capa de datos, (modelo E-R, consultas, SP. etc.) y despues de esto entra la logica del negocio y une las dos capas.

Julio. Que nos aconcejas?. y aprovecho para otra pregunta. tienes algun ejemplo de tres capas que tenga Linq.

muchas Gracias por tu colaboracion.

jtentor Argentina

Thursday, March 07, 2013 2:13 PM

jtentor

Estimado Rodrigo;

Eso que la logica de negocio une las dos capas no es así; la logica de negocio hace cosas necesarias para el negocio, como por ejemplo en un proceso de facturación validar ciertas caracteristicas de un cliente para poder aplicar un descuento.

De ninguna manera la logica de negocio se debe considear como un "adaptador" entre la capa de datos y la interfaz de usuario, para esos existen componentes que son justamente "adaptadores"; estos componentes se construyen cuando las dos cosas que necesitamos que colaboren o interactuen presentan interfaces diferentes, entonces hacemos un adaptador como los de la corriente de dos a tres patas o al reves.

Tampoco es correcto decir que como tengo la interfaz de usuario continuo con la logica de negocio para poder escribir un documento con las necesidades de datos. De ese modo la capa de datos indirectamente es dependiente de la interfaz de usuario; cuando en realidad ambas capas son dependientes de las necesidades del cliente, una misma capa de datos puede tener dos interfaces de usuario, una para pc y otra para tablet.

De manera que no importa que se continua haciendo, es más si se tiene dos equipos de trabajo podría encargarse a cada uno de ellos una capa diferente. Pero para eso lo que se necesita tener es la interfaz definida.

Cada capa se relaciona con otras mediante una interfaz perfectamente definida. En consecuencia lo primero que deberían hacer es definir las interfaces y luego todos pueden construir las capas respetando las interfaces.

Es probable que ciertas partes de la interfaz de usuario no muestre o requiera algunos atributos (campos) de objetos que se almacenan en la base de datos, de manera que el desarrollo de todas las partes debería ser INCREMENTAL y no como lo estas pensando uno despues del otro.

Pensar en utilizar una arquitectura en capas es trabajr un poco más ahora para que en el futuro sea mas facil hacer que el producto evolucione, a lo mejor tengo que almacenar en otro formato y debo descartar mi actual base de datos para almacenar la información en otra; una arquitectura en capas me permitira con tranquilidad implementar ese cambio o requerimiento de mantenimiento.

Finalmente mi sugerencia es que en una mañana o tarde de trabajo definan las interfaces escenciales entonces cada uno podrá avanzar con el contenido de cada capa tratando de mantener las interfaces. Por supuesto que no se va a poder, entonces en un par de dias en una nueva reunión informan los cambios que hacen falta en las interfaces y avanzan en el proceso de desarrollo.

Cuando digo interfaces lo hago genéricamente, también puede ser clases abstractas que luego se especializaran en otras clases. Por ejemplo en un sistema de facturación se puede pensar que la interfaz de usuario recibe un objeto que implementa la interfaz IFacturable que tiene ciertos metodos que le pertine interactura en un proceso de facturación, de ese modo nos olvidamos de la clase del objeto simplemente pensamos en su comportamiento. Igualmente ocurre en la logica de negocio el objeto IFacturable puede ser un producto (lapices) o un servicio (horas de chofer) que obviamente son objetos de clases diferentes, sin embargo ambos implementan las operaciones necesarias para ser facturados. Luego cada objeto implementará mecanismos de almacenamiento seguramente tambien bajo la forma de interfaces de manera que podrán realizarce con diferentes objetos.

No tengo ejemplo en Linq. Espero que les sirva.

Christian Ecuador

Sunday, April 21, 2013 3:04 PM

Christian

Hola Julio.
Muy bueno tu artículo y quiero ponerlo en práctica en c# y con oracle.
Tengo un par de preguntas que me gustaría me aclares.

Las 4 capas del nivel de aplicación que se observan en la figura #7 puede ser convertidas en DDLs?
es decir cada una puede ser un proyecto en C# y pueden ser referenciadas  una a la otra respetando la secuencia?

Y la única capa del nivel de datos de la figura #7, se refieren a los triggers, stored procedures y functions de la base de datos?
es decir todo el código que se pueda escribir con PL/SQL(oracle) o T-SQL (MS sql server)?

Sí tuvieras código fuente en c# de este esquema que necesito y que puedas compartirme te agradecería mucho.

Gracias.

jtentor Argentina

Sunday, April 21, 2013 8:42 PM

jtentor

Estimado,

Efectivamente cada capa puede ser un DLL, de este modo en el futuro sería posible cambiar uno de ellos respetando las interfaces de comunicación.

Cuando se trata de un pequeño proyecto, puede ser un espacio de nombres (namespace) dentro del mismo DLL, pero en el futuro los cambios implicaran la recompilación completa del producto; lo que no es grave pero puede haber dependencias no pensadas.

Lo que yo denomino capa/nivel de datos se trata de todo lo que puedas o debas hacer en el motor de base de datos, como tu dices PL/SQL o T-SQL; basicamente procedimientos almacenados, funciones, vistas que oculten las verdaderas tablas, etc.

Si la portabilidad es un problema, la interfaz (procedimentos y funciones) deberían respetar los estándares y no utilizar las particularidades que cada motor de base de datos ofrece, esto facilita la capa siguiente que es la de acceso a datos; caso contrario esta capa (la de acceso a datos suele ser muy dependiente del motor de base de datos).

Muchos productos reemplazan la capa de acceso a datos con un ORM del tipo NHibernate (en el caso de C#), actualmente Microsoft ofrece productos con funcionalidad de capa de acceso a datos como ser el Entity Framework y todo lo que tiene que ver con LINQ; prometen la independencia del motor de base datos o en todo caso la total dependencia de su producto.

Mi experiencia me indica que vale la pena hacer un esfuerzo (diseño y desarrollo) para aprovechar las ventajas/particularidades de los motores de base de datos, claro que debe documentarse bien para poder portar el producto a otro motor, suele suceder cuando se desarrolla un producto pequeño que resulta ser un "hit" y luego requiere mayor potencia en la base de datos. Muchos problemas surgen por el crecimiento en el volumen de datos y la cantidad de transacciones por unidad de tiempo.

Puedes ver un ejemplo de capas de acceso a datos y capa de datos en este proyecto https://anotherblog.codeplex.com/, te bajas el codigo y lo revisas; en AnOtherBlog.Core.Providers.SQL puedes ver el código para acceder a los datos en una base de datos relacional. Tal como esta planteado el producto utiliza una fabrica abstracta (patron de diseño) para el proveedor de datos, lo que permite cambiar este producto desarrollando las clases necesarias sin tener que manipular el resto del proyecto.

Espero que te sirva.

Janier Mexico

Monday, April 29, 2013 5:58 PM

Janier

Hola Julio, primeramente felicitarlo por el gran post que ha creado.

Quisiera hacerle una pregunta.

He desarrollado en sistema en Java el cual no usa base de datos, sino ficheros de texto almacenados en directorios en la PC. El sistema tiene entidades y una clase controladora, la cual gestiona los ficheros y las ventanas(GUIs) del sistema

Necesito que ese sistema tenga la arquitectura en N-Capas

alguna sugerencia ???

Gracias de antemano

jtentor Argentina

Tuesday, April 30, 2013 10:19 AM

jtentor

Por lo que dices, tu clase controladora tiene dos responsabilidades muy importantes y que yo recomendaría separar.

Una de ellas es gestionar los ficheros, que en tu caso viene a ser la capa de acceso a datos; la otra responsabilidad es la de manejar la interfaz de usuario que no es un tema menor.

Yo recomiendo separar estas responsabilidades en dos clases o capas (en tu caso hasta pueden ser packages) para que de ese modo la capa controlador (pura), la que dialoga con la interfaz de usuario solo reciba información de otros objetos que serán los encargados de gestionar los ficheros.

Si te tomas el trabajo de definir unas cuantas interfaces, para definir el comportamiento necesario para manejar la interfaz de usuario y otras para definir el comportamiento de gestión de datos entonces podrías desarrollar clases que implementan esas interfaces con la ventaja que en el futuro podrías cambiar la interfaz de usuario o la forma de almacenar los datos y tu aplicación continuaría sin problemas porque no tienes una clase que asume ambas responsabilidades.

Obviamente esto se piensa y diseña cuando alguien lo paga, cuando es un trabajo pequeño suele ser mas rápido utilizar un wizard que crea unas cuantas clases que lo hacen todo. Por supuesto en el futuro hay que tirar eso a la basura y hacer un nuevo prouducto, esto hasta puede ser redituable para los que viven de hacer software; sin embargo cuando se trata del ciclo de vida completo, desarrollo y mantenimiento es prudente pensar en los años que ese producto debe continuar funcionando y adaptandose a nuevo hardware, tendencias de mercado, etc.

Tu proyecto tiene una apariencia a MVC (Model-View-Controller), que es una arquitectura en capas solo que el controlador se encarga del "control" de la interfaz de usuarios y el modelo (model) vendria a ser tus entidades que supuestamente obtienen su contenido de algun lado; eso viene a estar detras como una capa o clases encargadas del almacenamiento.

Para que la arquitectura en capas se visualize con claridad te sugiero que utilices packages diferentes para cada clase dentro de una estructura jerárquica de nombres.

Espero que te sirva.

Oscar Mancera Colombia

Tuesday, April 30, 2013 12:31 PM

Oscar Mancera

Simpre leo las actualizacinoes de este post, y me permito con mucho respeto decir que es una gran contribucion al conocimiento colectivo. Muchas gracias.

Hugo Chile

Tuesday, June 11, 2013 7:08 PM

Hugo

Excelente el blog y el artículo. Y el conocimiento vertido al responder los comentarios. Se agradece.

Pingbacks and trackbacks (1)+