design-patterns - gof - head first design patterns
¿Permites que el Nivel Web acceda directamente al DAL? (7)
En mi opinión, SIEMPRE debería usar un BLL ( Capa de lógica de negocios ) entre su nivel web y su DAL ( Capa de acceso a datos ).
Aprecio que para algunas de las consultas más "simples", el BLL imitará de cerca al DAL (por ejemplo, Fetch todos los países, Fetch todos los tipos de productos, etc.), pero para ser honesto, incluso en su ejemplo:
(Traiga a todos los clientes con el apellido de ''Atwood'')
aquí se expresa la "lógica empresarial": ¡un deseo de que los registros de datos se filtren por apellido, por lo menos!
Al implementar un BLL desde el inicio de un proyecto, resulta increíblemente fácil insertar validación o "lógica" adicional cuando sea necesario (y si su proyecto es una aplicación comercial, es casi seguro que esa necesidad surja eventualmente si no es así). No hay al principio del proyecto). Añadiendo lógica adicional como:
Traiga a todos los clientes que han gastado más de $ 10000 este año
o
No permita que los clientes con el apellido ''Atwood'' compren artículos de más de $ 1000
se vuelve significativamente más fácil cuando se trata de un verdadero BLL, en lugar de intentar agrupar esta lógica en el nivel web.
Tenga en cuenta que con los tipos de consultas anteriores, es casi seguro que estamos hablando de múltiples entidades y tablas de base de datos que deberán unirse con relaciones específicamente definidas para implementar esta funcionalidad. Tratar de lograr esto manipulando directamente el DAL se vuelve desordenado, ya que estará tratando con múltiples entidades y clases. Un BLL aquí simplificaría enormemente su código de nivel web, ya que el BLL encapsulate esas relaciones de entidad detrás de una interfaz enormemente simplificada.
Esta " separación de preocupaciones " se vuelve cada vez más importante cuando y si surge la necesidad de cambiar la interfaz de usuario.
En al menos dos ocasiones separadas, he trabajado en aplicaciones web comerciales con una interfaz de usuario de sitio web, y finalmente se me ha solicitado (debido a la necesidad comercial de clientes que buscan una mayor integración con sus productos de software) para producir una interfaz de servicio web ofreciendo exactamente la misma funcionalidad que el sitio web.
Si hubiera incrustado alguna lógica empresarial en mi nivel web, habría tenido que duplicar y reescribir esa lógica al implementar mi servicio web. Tal como estaba, me aseguré de que toda la lógica de negocios estuviera encapsulada dentro de las clases BLL, lo que significaba que simplemente tenía que diseñar una serie de llamadas a los métodos de interfaz de servicio web, y conectarlas a las llamadas a los métodos en las clases BLL (en realidad usé el Patrón de diseño de fachada en lugares para simplificar la API de servicios web).
En general, no se me ocurre ninguna razón para NO incluir una capa BLL entre mi DAL y mi nivel web.
Cuando es más fácil, cuando el BLL "imita" al DAL, sí, parece que hay una duplicación de código y funcionalidad, sin embargo, aunque es un poco más de escritura, esto también hace que sea relativamente fácil de implementar.
Cuando está más involucrado (como cuando existe una lógica de negocios significativa desde el principio), la separación de preocupaciones ayuda a reducir la repetición (el principio DRY ) y, al mismo tiempo, simplifica significativamente el mantenimiento futuro y continuo.
Por supuesto, esto supone que estás haciendo todo esto "a mano". Si lo desea, puede simplificar significativamente las capas DAL / BLL / UI utilizando un ORM del cual hay muchos. (es decir, LINQ-to-SQL/Entities , SubSonic , NHibernate , etc.)
Estoy interesado en la percepción de "mejores prácticas", moderada con una pequeña dosis de realidad aquí.
En una aplicación web, ¿permite que su nivel web acceda directamente al DAL, o debe pasar por un BLL primero?
Estoy hablando específicamente de escenarios en los que no hay una "lógica de negocios" realmente involucrada, como una simple consulta: "Llamar a todos los clientes con el apellido de ''Atwood''". Los escenarios donde hay algún tipo de lógica que van a pasar por el BLL, así que llamémoslo moo .
Si bien puede encapsular este método dentro de un objeto BLL, parece ser algo inútil cuando a menudo la firma será exactamente la misma que la del objeto DLL, y el código probablemente sea tan simple como el de una línea que delegue la consulta en el DLL. .
Si elige el primero (empleando un objeto BLL), ¿cómo se llama a estos objetos? (Suponiendo que hagan poco más que proporcionar una capa de consulta en la DLL). Ayudantes? QueryProviders?
Pensamientos por favor.
Saludos
Marty
Hemos tendido a usar el patrón de fachada para el acceso, aunque nuestro proyecto en el que lo usamos es considerable, creo que puede resultar excesivo en un proyecto más pequeño.
Esencialmente:
UI -> BusFacade -> BusinessLogic -> DalFacade -> DataAccessLayer
La fachada proporciona un enfoque agradable / limpio desde la interfaz de usuario, y lo obliga a estandarizar sus convenciones de nombres, ya que ese único punto de entrada tiene varios métodos.
BusFacade.GetCmsSiteMap()
BusFacade.GetProductGroup()
etcétera etcétera.
Incluso cuando está encendida, y una línea en el BLL hace una llamada similar a la DLL, la abstracción le permite agregar lógica de negocios en esa capa sin tener que afectar a ninguna otra capa. Puede que ahora no parezca que esto es probable, pero quienquiera que tenga que respaldar la aplicación después de que te agradezca por usar patrones como este cuando se producen cambios.
En cuanto a la denominación, tengo mi objeto central, di un cambio de nombre, luego tendré un objeto BLL que es una persona que acepta un objeto de cambio de nombre, luego tendré un objeto DAL / Entidad llamado Persona. El objeto Business Person está dentro del espacio de nombres BLL, y el objeto DAL / Entity Person está en el espacio de nombres DB (habría elegido DAL si lo hubiera creado originalmente).
No estoy de acuerdo con la mayoría de los mensajes aquí.
Llamo a mi capa de datos en el nivel web. Si no hay nada entre el nivel WEB / UI, no tiene sentido crear una capa "por si acaso". Es la optimización previa. Es un desperdicio. No recuerdo un momento en que la capa empresarial "me salvó". Todo lo que hizo fue crear más trabajo, duplicación y mayor mantenimiento. Pasé años suscribiéndome a Business Layer -> Data Layer pasando las entidades entre las capas. Siempre me sentí sucio creando pases por métodos que no hacían nada.
Después de que Eric Evans me introdujera en Domain Driven Design , hago lo que tiene sentido. Si no hay nada entre la interfaz de usuario y la capa de datos, llamo a la capa de datos en la interfaz de usuario.
Para permitir futuros cambios, envuelvo todas mis clases de capa de datos en interfaces. En la interfaz de usuario, hago referencia a las interfaces y uso la inyección de dependencias para gestionar la implementación. Después de hacer estos cambios, fue como un soplo de aire fresco. Si necesito inyectar algo entre la capa de datos y la IU, creo un servicio.
Otra cosa que hice, fue reducir el número de proyectos. Antes de tener un proyecto para la capa de datos, la lógica de negocios, las entidades comerciales y algún tipo de proyecto de UI, qué molestia.
Tengo dos proyectos: el proyecto principal (entidades, lógica de negocios y capa de datos) y los proyectos de interfaz de usuario (web, servicios web, etc.)
Para más información recomiendo mirar a estos chicos:
Nos referimos a esta capa como una clase de controlador [capa] que encapsula el DAL del nivel web. La capa del controlador puede o no tener ninguna lógica de negocios, ayuda a separar el DAL de la capa de presentación y mantenerlos independientes [hasta cierto punto].
Si bien sería posible pasar directamente de la capa de presentación a DAL, se omitirá el BLL, que a menudo requiere autenticación ...
Debe distinguir los objetos BLL (¿qué diablos son estos? ¿Objetos de dominio de alguien?) Y Servicios. Los objetos de su dominio no deberían tener nada que ver con su capa de acceso a datos. En lo que respecta al nivel web, puede tratar sus repositorios (piense en IRepository ) como cualquier otro servicio que pueda usar libremente.
Por lo tanto, la conclusión es: sí, el nivel web puede usar DAL directamente, siempre que su propiedad esté encapsulada y se represente como un servicio de nivel de servicio estándar.