Comentarios de la arquitectura de nivel n necesarios

Question

Comencé mi sitio web, como stackoverflow, con una pequeña deuda técnica que estoy tratando de pagar. Como desarrollador por contrato, he estado en muchos lugares y veo muchos métodos diferentes para lograr este resultado, pero la forma en que me dirijo es ...

Presentación (web)

Business Layer (clases de entidad antiguas y capa BL)

Capa de datos (clases DA a SQL Server a través de proceso almacenado)

Mi pregunta concierne principalmente a la capa empresarial. Ahora mismo tengo un espacio de nombres de Entidad y un espacio de nombres de BusinessLogic.

El BL tiene una referencia al DA y la Entidad. La Entidad tiene una referencia al DA. (El DA es " inconsciente " del BL o Entidad)

Realmente quiero que todos mis cambios de datos se conviertan en entidades dentro del BL, por lo tanto, la lógica empresarial. Sin embargo, quiero que la Entidad pueda acceder a la BL si es necesario, y así eliminar la referencia de la Entidad a la DL.

Entonces ...

Es " incorrecto " ¿Tener los objetos BL y Entidad dentro del mismo espacio de nombres para que puedan trabajar juntos?

Esencialmente, estoy intentando tener un objeto de entidad como Empleado (ejemplo clásico, ¿eh?) y hacer que el Empleado tenga un

public Hashtable[] SubordinateEmployees

propiedad que devuelve un Hashtable de otros objetos Employee que informan a este empleado. Pero no quiero cargarlo hasta que sea necesario. Por lo tanto, para la mayoría de los empleados nunca se podría acceder a la propiedad, pero cuando lo hace, se carga automáticamente con una llamada al BL, que llama al DA.

¿Tiene sentido la pregunta?

Si es así, ¿mi solución?

¡Muchas gracias de antemano!

Answer 1

La forma habitual de lidiar con el tipo de situación que representa su ejemplo es con fachadas. En lugar de intentar obtener los empleados subordinados del objeto Employee, utiliza una llamada a la lógica de negocios para obtenerlo.

hashtable = BL.GetSubordinateEmployees(supervisor);

De esa manera, tiene un único punto de acceso a los subordinados, y solo hay una cosa (la BL) que accede a la capa de datos y crea Entidades.

Answer 2

Déjame ver si puedo mostrarte una mejor manera de pensar sobre esto

usted tiene su acceso a datos (servidor sql, mysql, archivos xml planos, etc.), todo esto se debe abstraer, nada más en su aplicación debería importarle o saber cómo está obteniendo sus datos, solo que la dosis, si cualquier otra cosa sabe cómo está obteniendo sus datos, tiene una violación de capa. Si el DAL dosifica cualquier otra cosa, entonces obtenga los datos que tiene una violación de capa. Luego, implementa una interfaz de acceso a datos, como IDAL, que utiliza su capa de negocios, esto es muy importante para hacer que su código sea verificable al obligarlo a separar sus capas.

Sus entidades de datos se pueden colocar en el espacio de nombres DAL o darles su propio espacio, dándoles la separación de fuerzas. Las entidades de datos son objetos tontos y deben contener muy poca o ninguna lógica y solo son conscientes de sí mismas y de los datos que tienen, NO CONTIENEN LA LÓGICA DE NEGOCIOS, LOCIC DE ACCESO A LOS DATOS, O LA LÓGICA DE UI. Si lo hacen tienes una violación de capa. La única función de una entidad de datos es mantener los datos y pasar de una capa a la siguiente.

La capa de Biz implementa una interfaz de acceso a datos como el IDAL del que hablamos antes de que pueda crear una instancia con una fábrica, un contenedor IOC, o todo lo demás que falle en un tipo concreto, pero agregue una propiedad de establecimiento para que esto pueda cambiarse para la prueba. Biz Layer Only maneja la lógica de negocios, no sabe ni le importa de dónde provienen los datos ni a dónde va, solo se preocupa de manipular los datos para cumplir con las reglas de negocios, esto incluiría la validación de fechas, el filtrado (parte de esto es indicando al DAL qué datos necesita, deje que el DAL descubra cómo obtenerlos. Básicamente, el BIZ maneja toda la lógica que no está relacionada con la IU o con la recuperación de datos. Al igual que el DAL, el Biz debe implementar una interfaz por el mismo motivo.

La capa UI Accede a la capa Biz de la misma manera que la capa Biz accede a la DAL por la misma razón. Todo lo que le importa a la capa de UI es mostrar datos y obtener datos del usuario. La capa de IU no debe saber nada acerca de las reglas de negocios, con la posible excepción de la validación de datos requerida para completar las entidades de datos.

La ventaja de esta arquitectura es que fuerza la separación de la preocupación, lo que hace que sea más fácil de probar, más flexible y más fácil de mantener. Hoy está creando un sitio web, pero mañana desea permitir que otros integren vi a un servicio web, todo lo que tiene que hacer es crear un servicio web que implemente la interfaz de IBIZ y listo, cuando tenga que corregir un error en el BIZ. Capa, ya está arreglado tanto en su sitio web como en su servicio web.

Llevando esto al siguiente nivel, digamos que está haciendo muchos cálculos de números pesados ??y necesita servidores más potentes para manejar esto, así que todo lo que tiene que hacer es implementar una interfaz IDal e IBIZ que realmente sean envoltorios para WCF que maneja la comunicación entre sus servidores, ahora su aplicación se distribuye entre varios servidores y no tuvo que cambiar su código para hacerlo.