Vorteile und Nachteile der Verwendung von Enterprise-Bibliothek

Question

Ich starte gerade ein Projekt und da dieses Projekt persönlich ist, fragte ich mich, was sind die Vorteile der Verwendung von Enterprise Library? Wir verwenden die Version 2 für mehrere Projekte im Büro, aber ich bin nicht ganz sicher (abgesehen von den guten Praktiken) der Vorteile davon, besonders in der Datenbankkomponente. Irgendein Rat? Danke

Answer 1

Für den Datenbankanwendungsblock besteht der Hauptvorteil darin, dass es einfacher ist, datenbankunabhängigen Code zu erzeugen. Der Entwickler interagiert hauptsächlich mit generischen Datenbank- und DbCommand-Objekten, anstatt zB mit SqlConnection, SqlCommand usw. Somit wird der Wechsel zu einer anderen Datenbank (dh Oracle) machbarer. Abhängig von Ihren geschäftlichen Anforderungen könnte dies ein klarer Vorteil sein. EntLib bringt den Entwickler auch sanft in Richtung der Verwendung von DbParameter für Abfrageparameter, was das Risiko von SQL-Injection-Angriffen reduziert.

Wie ein anderes Poster erwähnt, ist der Daten-App-Block etwas höher als die geraden ADO.NET-Klassen, so dass es weniger Codezeilen benötigt, um dasselbe zu tun.

Aus meiner Sicht sind die Daten, Ausnahme und Protokollierungsblöcke am nützlichsten. Exception und Logging zusammen machen es sehr einfach, Ausnahmen (duh) an einer Reihe von Orten und in einer Reihe von Formaten zu protokollieren. Zum Beispiel können sie den gesamten Ausnahmeprotokolleintrag, einschließlich der Stack-Ablaufverfolgung, in das Windows-Ereignisprotokoll aufnehmen, wodurch die Diagnose eines Problems relativ einfach wird.

Ein Nachteil von EntLib ist, dass einige App-Blöcke ziemlich viel Logik in Konfigurationsdateien stecken. Deine Logik ist also weiter verbreitet; einige davon sind in Code, einige in Konfigurationsdateien. Der Vorteil ist, dass die Konfiguration nach dem Build und sogar nach dem Deployment geändert werden kann.

Answer 2

Mein Team hat eine Evaluierung der Microsoft Patterns and Practices Enterprise Library vor etwa 2 Jahren im Rahmen einer Überarbeitung unserer Produktlinie vorgenommen. Der einzige Teil, den wir am Ende benutzten, war der Datenbankblock. Wir haben das sogar in einige Klassen eingebaut, die wir instanziieren konnten, damit wir die DAL für Unit-Tests verspotten konnten; Der Microsoft-Codeblock verwendete statische Aufrufe für die Datenbankarbeit. Ich bin mir nicht sicher, ob Microsoft das LINQtoSQL- oder Entity Framework-Zeug in den DB-Block integriert hat. Ich würde zögern, den db-Block jetzt zu benutzen, wenn er einen davon nicht ausnutzen würde.

Soweit Protokollierung geht, fanden wir Log4Net eine viel robustere und flexible Lösung, die Microsoft Protokollierung. Wir sind damit für unseren Holzbedarf gegangen.

Für die Ausnahmebehandlung rollten wir unsere eigenen. Der Microsoft-Code behandelte nicht die Remoting-Fälle, die wir behandeln wollten, und da wir ein Logging-Framework von Drittanbietern verwendeten, war es sinnvoller, unsere eigene Exception-Bibliothek zu schreiben und sich damit zu integrieren. Ich habe herausgefunden, dass ein gewisses Maß an Integration des Logging-Frameworks in das Exception-Framework sehr nützlich sein kann. Wir haben einige einfache Wrapper-Klassen um Log4Net geschrieben und diese aus unserer Exception-Logging aufgerufen, so dass wir keine Abhängigkeiten zu Log4Net eingeführt haben.

Answer 3

Zusätzlich zu den von Paul erwähnten Punkten über den Datenanwendungsblock möchte ich auch darauf hinweisen, dass der Datenanwendungsblock meiner Erfahrung nach viel schneller ist, um den benötigten Datenbankcode mit den vorhandenen Helfern zu schreiben . Ich benutze es für sein einheitliches Aussehen/Gefühl und die Geschwindigkeit der Entwicklung.