DAL und BLL in .NET
Gibt es diese DAL/BLL-design Vorschlag von Microsoft für ASP.NET (2.0) - apps. Ich weiß, dass einige der alternativen und ich habe gelesen Fragen hier SO. Allerdings Frage ich mich, ob mit der hier vorgeschlagenen Lösung ist es Wert Umsetzung heute gibt es einen Nachteil, die Sie kennen?
Möchte ich entwickeln DAL/BLL-Komponenten für Unternehmens-interne Nutzung, Zugriff auf Kunden-und Mitarbeiter-Daten, usw. von verschiedenen Anwendungen und Skripts. Aber bevor ich mit dem Bau beginnen, die Sachen, die ich sicher sein wollen, dass diese Lösung "gut". Als Beispiel, die BLL geht datatables anstelle der Kapselung nichts, Sie müssen nicht isoliert, business-Objekte, die Logik enthalten. Es ist im Grunde nur eine dumme Schicht, erleichtert die CRUD-Operationen ein wenig und ermöglicht eine Datenbindung für Steuerelemente.
Könnte jemand, hat wer Erfahrung in diesem Bereich, zeigen mir die pro 's und con' s von diesem Ansatz?
- Sie entwickeln sowohl BAL DAl verwenden Sie folgenden link c-sharpcorner.com/UploadFile/paulabraham/... Wo Quellcode,demo und Erklärung gegeben
Du musst angemeldet sein, um einen Kommentar abzugeben.
Vorteile:
einfache Vorgehensweise und einige der Daten, die Zuordnung erfolgt für Sie mit der datatable ist.
- bietet einige Bequemlichkeiten für das brennen Auswählen, Hinzufügen, Aktualisieren und Löschen Abfragen.
- geeignet sein könnte, für sehr einfaches design mit wenigen Tischen.
geeignet für non-self-referencing ER degigns oder ER ist mit wenigen lookup-Tabellen und einfache/wenige joins
geeignet, wo einfache speichern von Daten erforderlich ist. dh. wo komplexe OO-Ideen, die angewendet werden sollte, um die "business-Objekte" dieses Muster würde die Dinge schwieriger.
Nachteile:
große OO-Modelle wird der Kampf in dieses Muster
- ER komplexe designs mit vielen Tabellen, komplexe Zusammenhänge oder OO-Objekt, die die Anforderungen nicht passen in dieses Muster. die datatables-dont bieten viel Unterstützung für die in-code-Objekt Abfragen wie LINQ.
- die meisten Abfragen geschrieben werden müssen von hand in SQL (dieses enthält Verknüpfungen). ja, Sie können den Abfrage-designer, aber das dont viel helfen.
- es gibt eine Menge von code-Duplizierung in diesem Ansatz. wie Sie schreiben, viele CRUD-Methoden in Ihrem BLL-Klassen (die Sie auch schreiben müssen, von Grund auf).
Fazit:
es hängt wirklich von Ihren Anforderungen. wenn Ihre Implementierung ist kleiner, einfacher, dann könnte dies eine gute Idee. aber wächst auf einer kleinen Idee wird schwer sein mit diesem Ansatz. eine weitere OO-Ansatz, können Sie viel besser für die Umgestaltung/Erweiterung später.
dieses Muster ist auch älter/veraltet. Objekt Abfragen IQueryable/LINQ wird immer beliebter und wird ein breiter standard kurz. ich würde vorschlagen, u springen an Bord dieser Wagen. es wird besser sein für Ihre persönliche Entwicklung auf lange Sicht zu. 😀
einige links:
Ich voll und ganz empfehlen, NICHT MIT DATATABLES. Blick in eines domain-driven design, Implementierung, dass der gesamte Rahmen wird die Arbeit mit regulären Objekten, die Sie übergeben können, die in der Liste<> oder Queryable<>. DataTables sind Müll, der gar nicht aufgenommen werden .NET mehr.
Ich würde auch empfehlen, sich in einem Dependency Injection /Inversion of Control framework wie Microsoft Unity oder StructureMap erstellen von lose gekoppelten code.