La arquitectura en capas tienen como motivo principal:
1- Fácil de mantener
2- Escalable
3- Fácil de probar usando Unit Test
Pensando en estos 2 motivos es que muchas empresas contratan arquitectos de software para poder poner las cosas en su lugar y así tener un sistema más estable. La estabilidad se logra entre pruebas y arreglos de errores, pero sino es un código con las 2 características que indico arriba será una tarea casi imposible.
Ahy muchos patrones que dan rumbo a codificación estable y lamentablemente nadie jamás habla de ellas. Los patrones en su mayoría están diseñados en capas. Ahora bien veamos unos patrones que serán de muchísimo uso para tí así entenderás en un corto plazo donde poner cada parte de tu código.
1- Data Layer
Este es por si mismo el más importante debido a que la mayoría de los programas guardan su información o interactuan con base de datos. Pero lamentablemente este layer puede estar tan desacoplado entre sus miembros mezclando más patrones para tener una estructura más robusta que permita un alcanze más preciso a futuros cambios.
Aquí solo te hablaré de 2 patrones en especial.
1- Domain Model
2- Repository Pattern
Domain Model
Domain Model es el conjunto de clases que tienen un significado lógico para el negocio y que representan un tipo especifico de objeto en la base de datos. Un ejemplo simple es por ejemplo un cliente. Para la empresa un cliente es una objecto que tiene como propiedades nombre, apellido, edad, cedula, dirección, etc etc.
Todas esas propiedades representan una columna de la tabla Cliente de la base de datos. Entonces para nosotros los programadores buscando metodologias y patrones buenos llegamos a lo que son los ORM. El mapeo relacional de objetos es una conversión de row de una tabla a una clase en memoria. Osea que a la tabla Cliente se le crea una clase Cliente con todas las propiedades. Los ORM de microsoft como EntityFramework y Linq to Sql hacen este trabajo por nosotros. Puedes informarte en google de estos 2 ORM de microsoft.
Los ORM nos generan las clases que representarán nuestro Domain Model. Haciendo uso de un tool ORM como Entity Framework podemos convertir la base de datos en clases que menos de 1 minuto y el genera todo por nosotros.
Repository Pattern
Este patrón nos ayuda a tener un código limpio y es nuestro punto de acceso a los datos. Debe quedar claro que el no valida nada, los datos que se le pasan a el deben ya venir limpios y al invocar algún método de algún repositorio es porque la data va segura, ya más adelante explico quien valida.
El repositorio es una clase que interactua con 1 tipo especifico del Domain Model y la base de datos. Y Siempre devuelve un objeto jamas devuelve un pedazo del objeto.
Una clase ejemplo seria ClienteRepository con métodos como por ejemplo ObtenerCliente(int id), CrearCliente(Cliente obj).
Cada método tiene la lógica necesaria que la representa, ejemplo:
Código C#:
Ver originalpublic void CrearCliente(Cliente obj)
{
context.AddToCliente(obj);
}
El context es un ObjectContext generado por el EntityFramework, cuando leas sobre el EntityFramework entenderás esta parte.
Otro ejemplo sería:
Código C#:
Ver originalpublic Cliente ObtenerCliente(int id)
{
return context.Clientes.Where(c => c.ClienteID == id).FirstOrDefault();
}
Este con el ID te devuelve el objeto Cliente que fue encontrado en la base de datos. Los métodos que puede tener un Repositorio son 4 bases + todos los extras que quieras agregar. Buscate información de este patrón y verás más.
2- Service Layer o Controller Layer
El Layer de Servicio es una librería que tiene la lógica de validación, comparación, conversión, log de error y depuración, todo lo demás.
Aca puede hacerse uso de muchos más patrones cada uno para un caso específico pero veamoslo como nuestro Layer de lógica del negocio. Debes saber que la lógica de negocio es donde esta las reglas y validaciones propias del negocio.
Un ejemplo simple es que si un cliente solo es aceptado para mercado local aquí va lógica como por ejemplo, si el cliente es de Estados Unidos entonces lo agrego a la base de datos sino es de allá retorno un error diciendo que esta en un mercado fuera del rango de la empresa. Si en 2 años la empresa acepta de España solo haces cambio en el Servicio que tiene la lógica que valida esta información y listo.
3- Layer de Objetos Comunes.
En la actualidad ya muchos sistemas implementan servicios ya sea por soap ó tcp ip haciendo uso de Windows Communication Foundation. Sabemos que este framework cuando uno hace referencia a un servicio auto genera las clases y el proxy de comunicación pero integrando mejor seguridad y performance no se hace de este modo, el WCF framework nos permite hacer uso de su API para que nosotros mismos manipulemnos la configuración y el proxy de forma dinámica, eliminando la posibilidad de abrir el servicio para ser referenciado, entonces mientras más dividido tengamos nuestros objetos comunes normalmente llamados abstracciones de nuestro domain model también ponemos los contratos dentro de este layer.
Otro tipo de objetos que reciden alli son Excepciones propias, configuraciones, librerias de utilidades, librerias genericas, todo lo que sea reutilizable por muchos más sistemas.
QUE TENEMOS HASTA AHORA
Tenemos 3 proyectos
1- Company.Data
2- Company.Logic
3- Company.Common
Esto sería una base muy buena de arquitectura a seguir en cada proyecto con algunos patrones anidados cada uno en su layer especifico.
Ahora cuando entren los visuales solo serán para efecto de captura de ordenes que serán procesadas por los 3 proyectos de arriba.
Ahy un proyecto más que seria el Layer del ServicioWeb ó ServicioRemoto, que en realidad sería un facade. El facade es un patrón que es dar acceso a la librería pura pero depurando que es lo unico a lo que tendran acceso y que permisos requieren. Esta seria un WCF project y alli estarían las clases wrapper que son intermediarios con extra lógica de permisos y demás a la libreria Logic y sus servicios. En el WCF proyect solo pones lo que quieres que los proyectos Visuales tengan acceso de la libreria Logic.
Si quieres hacer un programa que su visual sea un web, y la información este en la base de datos, pero que el visual todo se lo pida a un servicio web tendrías los siguientes proyectos.
1- Data
2- Logic
3- Common
4- Services
5- Web
Espero haber ayudado un poco más con información relacionada a el tema arquitectura en capas.