Je pense que BLL est sur les données. Il ne doit pas inclure une méthode appelée SendEmail. BLL est un endroit pour mettre en cache des données, les manipuler, faire des calculs liés aux affaires. L'envoi de courrier électronique est un processus métier, mais le code qui envoie l'e-mail doit être en dehors de l'espace de noms BLL.Business Layer Logic (BLL) concerne les données?
La BLL concerne-t-elle uniquement les données?
BLL est pas données, il est tout au sujet de ce qui doit être fait avec les données.
utilisateur n'interagir avec les présentations-formes de toute application frontale, qui est généralement connu comme couche de présentation .
Les données seront affichées ou échangées en entrée/sortie sur cette couche à partir de diverses sources de données. Ces sources sont les suivantes: bases de données ou services Web. Le morceau de code qui extrait ou envoie ces données à des sources de données respectives est ce que nous appelons DAL - couche d'accès aux données.
Entre l'application effectue des opérations spéciales que nous appelons application des exigences ou utilisateur des besoins. Cette partie stratégique de l'application est appelée BLL qui en réalité répond aux besoins du client pour lequel vous développez l'application.
Si des données doivent être stockées dans la base de données, BLL aura DAL comme couche sous-jacente.
BLL est pas au courant des sources de données et la façon dont les données sont extraites ou envoyé aux données sources. Vous avez DAL pour cela. BLL connaît seulement des données, que dans des formes d'affaires-objets plus souvent et des opérations sur les
données
affaires-objets .
BLL aussi ne sait pas si l'utilisateur utilise un site Web ou une application de bureau. Vous avez une couche de présentation pour cela.
BLL correspond à votre couche logique métier. Il devrait gérer tout ce qui est lié à la couche logique de votre entreprise. SendEmail peut-être mieux dans une sorte de classe d'utilité? De plus, si vous informez votre BLL d'un mécanisme d'emailing, vous lui donnez trop d'informations (étroitement couplé, suivez la loi de demeter pour les fonctions, wiki/google). Votre BLL ne se soucie pas de l'email et ne devrait pas.
Lorsque vous avez mentionné données, vous êtes probablement après le DAL (couche d'accès aux données). C'est la couche qui traite les insertions/mises à jour de données, etc. vers une ressource telle qu'une base de données.
BLL n'est pas sur les données ... il s'agit de Business (par conséquent Business Logic Layer).
Le DAL est tout au sujet de données.
Je déplacerais probablement la méthode SendMail vers une classe Utility, mais il est parfaitement légitime que vous deviez appeler SendMail depuis le BLL.
Merci, et si vous avez une méthode appelée SendEmail dans BLL la méthode va effectivement faire plusieurs choses 1- En utilisant la classe utilitaire appelée Util il cryptera et enverra l'email. 2- Insérez le statut d'envoi dans la base de données via DAL. – Costa
Dans ce cas, je dirais que la BLL est l'emplacement correct pour la méthode ...Bien que le nom pourrait être un peu plus descriptif (pour se distinguer d'une méthode SendEmail de style utilitaire). –
Votre couche logique d'entreprise doit gérer les choses relatives à votre entreprise, pour dire que votre couche de gestion est uniquement sur les données ne serait pas tout à fait exact. Par exemple, de nombreuses personnes ont l'obligation de mettre en cache des données pour des raisons de performance, et ainsi dire que la mise en cache est spécifique à une entreprise serait incorrect.
Certains calculs (calcul d'un devis, par exemple) peuvent être considérés comme une logique métier, car ils ne concernent que votre activité. L'envoi de courriels n'est certainement pas une logique commerciale - il s'agit d'une exigence relativement générique qui n'est certainement pas propre à votre entreprise ou à votre secteur d'activité.
Si vous le regardez d'un point de vue de la couche, l'envoi de courriels s'intégrerait mieux dans la couche de présentation plutôt que dans la logique métier ou la couche de données. Toutefois, le déclenchement de l'envoi d'un e-mail peut provenir de la couche Busines et la couche de gestion ne doit pas appeler la couche de présentation.
Dans ce cas, une solution potentielle serait que la couche de gestion gère une file d'attente de courrier électronique et que la couche de présentation gère la collecte des courriels et leur envoi. Parfois, se conformer rigidement à un modèle peut causer plus de problèmes que ce que l'on cherche à résoudre. Si vous trouvez qu'une implémentation spécifique fonctionne pour vous maintenant et ne causera pas de problèmes à court ou moyen terme, et que le coût d'investigation et de mise en œuvre de la solution "parfaite" est trop élevé, alors faites ce que vous avez.
La couche Business doit contenir des classes qui contiennent des informations commerciales. Les classes de cette couche doivent représenter votre activité dans les logiciels. Les méthodes doivent impliquer des règles métier. La couche de gestion conservera, validera et manipulera les données, mais votre couche DAL (Data Access Layer) sous-jacente saura comment ajouter, supprimer, récupérer et mettre à jour les données de la base de données. La couche de gestion ne devrait pas non plus se soucier de la présentation. Par le passé, j'ai toujours travaillé sur des fonctions distinctes qui peuvent apparaître dans n'importe quel programme/entreprise, comme l'envoi d'un e-mail dans sa propre classe/méthode générique. La seule fois où j'ai vu une classe BLL liée à un e-mail, c'est lorsque la règle métier a été écrite pour envoyer un e-mail. Dans ce cas, la BLL connaissait le texte de l'e-mail à envoyer, mais instanciait la classe d'e-mail générale pour envoyer l'e-mail.
Sauf si votre entreprise envoie des e-mails. – cgp
@alt - Même si son entreprise veut envoyer un courriel, la définition de la façon d'envoyer un courriel ne devrait pas être définie à l'intérieur d'une BRL. Il devrait être séparé en une classe utilitaire. – JonH