Creo que BLL es sobre Datos. No debe incluir un método llamado SendEmail. BLL es un lugar para almacenar datos en caché, manipularlos y hacer cálculos relacionados con los negocios. El envío de correo electrónico es un proceso de negocios, pero el código que realmente envía el correo electrónico debe estar fuera del espacio de nombres BLL.Business Layer Logic (BLL) es sobre datos?
¿El código BLL es solo sobre datos?
BLL no se trata de datos, es todo acerca de lo que hay que hacer con los datos .
Usuario sólo va a interactuar con la presentación formas front-end de cualquier aplicación, que se conoce popularmente como capa presentación.
Los datos se mostrarán o intercambiarán como entrada/salida a esta capa desde varias fuentes de datos . Estas fuentes son bases de datos o web-services. El fragmento de código que realmente capta o envía estos datos a las respectivas fuentes de datos es lo que llamamos DAL - capa de acceso a datos.
En medio de la aplicación hace operaciones especiales que llamamos aplicación requisitos o necesidades de los usuarios. Esta parte estratégica de la aplicación se llama BLL que realmente atiende las necesidades del cliente para el que está desarrollando la aplicación.
Si los datos deben almacenarse en la base de datos, BLL tendrá DAL como capa subyacente.
BLL es no tiene conocimiento de las fuentes de datos y cómo datos se obtienen o se envía a fuentes de datos. Tienes DAL para eso. BLL solo sabe acerca de los datos, que en formas de objetos comerciales más a menudo y operaciones en los datos
business-objects.
BLL también no sabe si el usuario está utilizando el sitio web o una aplicación de escritorio. Tienes una capa de presentación para eso.
BLL significa la capa de lógica de negocios. Debe manejar todo lo relacionado con su capa de lógica de negocios. SendEmail puede ser mejor en algún tipo de clase de utilidad?
Además, si le dice a su BLL acerca de un mecanismo de correo electrónico le está dando demasiada información (estrechamente acoplado, siga la ley de demeter para funciones, wiki/google). Su BLL no se preocupa por el correo electrónico ni debería hacerlo.
Cuando mencionó Datos, probablemente esté detrás del DAL (Nivel de acceso a datos). Esta es la capa que trata con las inserciones/actualizaciones de datos, etc. de vuelta a algún recurso, como una base de datos.
BLL no se trata de datos ... se trata de negocios (de ahí negocio Logic Layer).
El DAL es todo sobre datos.
Probablemente mueva el método SendMail a una clase de Utilidad, pero es perfectamente legítimo que necesite llamar a SendMail desde el BLL.
Gracias, ¿Qué pasa si tienes un método llamado SendEmail en BLL? El método realmente hará varias cosas. 1- Utilizando la clase de utilidad llamada Util, cifrará y enviará el correo electrónico. 2- Inserte el estado de envío en la base de datos a través de DAL. – Costa
En ese caso, diría que el BLL es la ubicación correcta para el método ...aunque el nombre podría ser un poco más descriptivo (para distinguirse del método de envío de estilo de utilidad). –
Su capa de lógica de negocio debe manejar las cosas relacionadas con su negocio, decir que su capa de negocio solo se trata de datos no sería del todo exacto. Por ejemplo, muchas personas tienen el requisito de almacenar en caché los datos por razones de rendimiento, por lo que decir que el almacenamiento en caché es específico del negocio sería incorrecto.
Sin embargo, algunos cálculos (por ejemplo, el cálculo de una oferta) se pueden contar como lógica comercial, ya que son específicos solo para su empresa.
Enviar correos electrónicos definitivamente no es una lógica de negocios: este es un requisito bastante genérico y ciertamente no es específico de su negocio o industria.
Si lo miras desde una perspectiva de capa, el envío de correos electrónicos encajaría mejor en la capa de presentación en lugar de la lógica de negocios o la capa de datos.
Sin embargo, el desencadenamiento del envío de un correo electrónico puede provenir de la capa de negocio, y la capa empresarial no debe llamar a la capa de presentación.
En tal caso, una posible solución sería que la capa empresarial administrara una cola de correo electrónico y que la capa de presentación maneje recoger los correos electrónicos y enviarlos.
A veces, ajustarse rígidamente a un patrón puede causar más problemas de los que está tratando de resolver. Si encuentra que una implementación específica le funciona ahora y no le causará ningún problema a corto o mediano plazo, y el costo de investigar e implementar la solución "perfecta" es demasiado grande, entonces vaya con lo que tiene.
La capa empresarial debe contener clases que contengan información comercial. Las clases en esta capa deben representar su negocio en el software. Los métodos deben incluir reglas comerciales. La capa empresarial contendrá, validará y manipulará datos, pero su capa de acceso a datos (DAL) subyacente sabrá cómo agregar, eliminar, obtener y actualizar datos de la base de datos. La capa de negocios tampoco debería preocuparse por la presentación.
En los equipos anteriores siempre he trabajado en funciones separadas que pueden aparecer en cualquier programa/negocio como enviar un correo electrónico en su propia clase/método genérico. La única vez que he visto una clase de BLL tener algún vínculo con un correo electrónico es cuando se escribió la regla de negocios para enviar un correo electrónico. En este caso, el BLL sabía el texto del correo electrónico a enviar, pero creó una instancia de la clase de correo electrónico general para enviar el correo electrónico.
A menos que su empresa esté enviando correos electrónicos. – cgp
@alt: incluso si su empresa desea enviar un correo electrónico, la definición de cómo enviar un correo electrónico no se debe definir dentro de un BLL. Debe separarse en una clase de utilidad. – JonH