Ich denke BLL ist über Daten. Es sollte keine Methode namens SendEmail enthalten. BLL ist ein Ort, an dem Daten zwischengespeichert, manipuliert und betriebswirtschaftliche Berechnungen durchgeführt werden können. Das Senden von E-Mails ist ein Geschäftsprozess, aber der Code, der die E-Mail sendet, sollte sich außerhalb des BLL-Namespace befinden.Business-Layer-Logik (BLL) geht es um Daten?
Ist BLL nur über Daten?
BLL geht es nicht um Daten, Es geht darum, was mit den Daten getan werden muss.
Benutzer nur mit der Front-End-Präsentationsformen jeder Anwendung zu interagieren, die allgemein als Präsentationsschicht bekannt ist.
Daten werden von verschiedenen Datenquellen als Eingabe/Ausgabe für diese Schicht angezeigt oder ausgetauscht. Diese Quellen sind Datenbanken oder Web-Services. Das Codeelement, das diese Daten tatsächlich zu den jeweiligen Datenquellen holt oder sendet, ist das, was wir DAL - Datenzugriffsschicht nennen.
Zwischen der Anwendung führt spezielle Operationen, die wir anwendungs Anforderungen oder Benutzer-Bedürfnisse nennen. Dieser strategische Teil der Anwendung heißt BLL, dass tatsächlich Adressen Bedürfnisse des Clients Adressen, für die Sie die Anwendung entwickeln.
Wenn Daten in der Datenbank gespeichert werden müssen, BLL wird DAL als eine zugrunde liegende Schicht haben.
BLL ist keine Kenntnis von den Datenquellen und wie Daten abgerufen oder gesendet zu Datenquellen. Du hast DAL dafür. BLL kennt nur Daten, die in Form von Geschäftsobjekten häufiger vorkommen und Operationen aufBusiness-Objekte
.
BLL auch weiß nicht, ob Benutzer Website oder eine Desktop-Anwendung verwenden. Sie haben Präsentationsebene dafür.
BLL steht für Ihre Business-Logik-Ebene. Es sollte alles behandeln, was mit Ihrer Geschäftslogikschicht zu tun hat. SendEmail kann in einer Art Utility-Klasse besser sein?
Auch wenn Sie Ihren BLL über einen E-Mail-Mechanismus informieren, geben Sie ihm zu viele Informationen (eng gekoppelt, folgen Sie dem Demeter-Gesetz für Funktionen, wiki/google es). Ihr BLL kümmert sich nicht um E-Mails und sollte es auch nicht tun. Wenn Sie Daten erwähnt haben, sind Sie wahrscheinlich nach der DAL (Data Access Layer). Dies ist die Ebene, die sich mit Dateneinfügungen/-updates etc. zu einer Ressource wie einer Datenbank befasst.
BLL geht nicht um Daten ... es geht um Business (daher Business Logic Layer).
Bei der DAL dreht sich alles um Daten.
Ich würde wahrscheinlich die SendMail-Methode in eine Utility-Klasse verschieben, aber es ist vollkommen legitim, dass Sie SendMail von der BLL anrufen müssen.
Danke, wenn Sie eine Methode namens SendEmail in BLL haben, wird die Methode tatsächlich mehrere Dinge tun 1- Using Utility-Klasse namens Util wird es verschlüsseln und senden Sie die E-Mail. 2- Fügen Sie den Sendestatus über DAL in die Datenbank ein. – Costa
In diesem Fall würde ich sagen, dass die BLL der richtige Ort für die Methode ist ...obwohl der Name etwas beschreibender sein könnte (um sich von einer SendEmail-Methode im Utility-Stil zu unterscheiden). –
Ihre Business-Logik-Ebene sollte Dinge in Bezug auf Ihr Unternehmen behandeln, um zu sagen, dass Ihre Business-Schicht nur über Daten wäre nicht ganz genau. Zum Beispiel haben viele Leute die Anforderung, Daten aus Performancegründen zwischenzuspeichern, und so zu sagen, dass Caching geschäftsspezifisch ist, wäre falsch.
Bestimmte Berechnungen (z. B. das Berechnen eines Angebots) können jedoch durchaus als Geschäftslogik gelten, da sie nur für Ihr Unternehmen spezifisch sind.
Das Senden von E-Mail ist definitiv keine Geschäftslogik - dies ist eine ziemlich generische Anforderung und ist sicherlich nicht spezifisch für Ihr Geschäft oder Ihre Branche.
Wenn Sie es aus einer Ebenenperspektive betrachten, würde das Senden von E-Mails besser in die Präsentationsschicht als in die Geschäftslogik oder Datenschicht passen.
Das Auslösen des Sendens einer E-Mail kann jedoch vom Business-Layer ausgelöst werden, und der Business-Layer sollte nicht den Präsentations-Layer aufrufen.
In diesem Fall wäre eine mögliche Lösung für die Business-Schicht, eine E-Mail-Warteschlange zu verwalten, und die Präsentationsschicht kann die E-Mails abrufen und senden.
Manchmal kann die starre Anpassung an ein Muster zu mehr Problemen führen, als es zu lösen versucht. Wenn Sie feststellen, dass eine spezifische Implementierung jetzt für Sie funktioniert und kurz- bis mittelfristig keine Probleme verursacht und die Kosten für die Untersuchung und Implementierung der "perfekten" Lösung zu hoch sind, dann gehen Sie mit dem was Sie haben.
Die Business-Schicht sollte Klassen enthalten, die Geschäftsinformationen enthalten. Klassen in dieser Ebene sollten Ihr Geschäft in Software darstellen. Methoden sollten Geschäftsregeln beinhalten. Die Business-Schicht wird Daten halten, validieren und bearbeiten, aber Ihre zugrunde liegende Data Access Layer (DAL) wird wissen, wie Sie Daten aus der Datenbank hinzufügen, entfernen, abrufen und aktualisieren. Die Business-Schicht sollte sich auch nicht um die Präsentation kümmern.
In den vergangenen Teams habe ich immer an separaten Funktionen gearbeitet, die in jedem Programm/Geschäft erscheinen können, wie das Senden einer E-Mail in einer eigenen generischen Klasse/Methode. Das einzige Mal, dass ich eine BLL-Klasse gesehen habe, sind Verbindungen zu einer E-Mail, wenn die Geschäftsregel zum Senden einer E-Mail geschrieben wurde. In diesem Fall kannte die BLL den Text der zu sendenden E-Mail, aber instanziierte die allgemeine E-Mail-Klasse, um die E-Mail zu senden.
Es sei denn, Ihr Unternehmen sendet E-Mails. – cgp
@alt - Selbst wenn sein Unternehmen E-Mails senden möchte, sollte die Definition, wie eine E-Mail gesendet wird, nicht innerhalb eines BLL definiert werden. Es sollte in eine Utility-Klasse getrennt werden. – JonH