Ich habe einige andere Fragen zu diesem Thema gelesen ( hier hier und < a href="https://stackoverflow.com/questions/731763/should-c-methods-that-can-be-static-be-static"> hier ), aber haben noch eine große Antwort zu sehen . Ich habe meinen fairen Anteil an Datenzugriffsschichten schon früher entwickelt und bevorzuge es, anstelle von statischen Klassen Instanzklassen zu verwenden. Es ist jedoch eher eine persönliche Präferenz (ich teste gerne meine Geschäftsobjekte, und dieser Ansatz macht es einfacher, die DAL zu verspotten). Ich habe zuvor statische Klassen verwendet, um auf die Datenbank zuzugreifen, aber ich fühlte mich immer etwas unsicher in der Angemessenheit eines solchen Entwurfs (besonders in einer ASP.NET-Umgebung).
Kann jemand in Bezug auf diese beiden Ansätze zur Entwicklung von Datenzugriffsklassen mit ADO.NET-Providern (kein ORM), insbesondere in einer ASP.NET-Anwendung, einige gute Vor- und Nachteile bieten? Fühlen Sie sich frei zu schlagen, wenn Sie mehr allgemeine statische vs. Instance-Klassen-Tipps als auch haben.
Insbesondere geht es mir um folgende Punkte:
Danke!
Statisch basierte Ansätze haben in der Regel nur einen Hauptvorteil: Sie sind einfach zu implementieren.
Instanzbasierte Ansätze gewinnen für:
Statische Ansätze können gewinnen:
Im Allgemeinen finde ich, dass instanzbasierte Ansätze überlegen sind. Dies wird umso wichtiger, wenn Sie auch über einen einzelnen Server hinaus skalieren, da der statische Ansatz "zerbricht", sobald Sie ihn auf mehreren Rechnern instanziieren ...
Mein allgemeines Gefühl ist: Warum instanziieren, wenn Sie nicht müssen?
Ich verwende statische Klassen, wenn mehrere Instanzen nicht verwendet werden und keine Instanzmitglieder benötigt werden. Was die DAL betrifft, ist der Punkt, dass es nur einen gibt. Warum es instanziieren, wenn es keinen Wert darin gibt?
Sehen Sie sich diesen Link an, der zeigt, dass statische Methodenaufrufe schneller sind als die Instanzklassenmethode Anrufe.
Dieser Link zeigt, dass ein Vorteil der Verwendung einer statischen Klasse ist dass der Compiler überprüfen kann, dass keine Instanzmitglieder versehentlich hinzugefügt wurden.
Dieser Link zeigt, dass eine statische Klasse als praktischer Container für Mengen von verwendet werden kann Methoden, die nur mit Eingabeparametern arbeiten und keine internen Instanzfelder abrufen oder setzen müssen. Für eine DAL ist dies genau das, was Sie haben. Es gibt keinen Grund, interne Instanzfelder zu erstellen und daher keinen Grund für die Instanziierung.
Ich verwende seit Jahren eine statische DAL und stimme Ihren Bedenken zu. Threading und Parallelität ist die größte Herausforderung und in meinem Fall speichere ich verschiedene Verbindungsobjekte in statischen Thread-Strukturen. Es hat sich als sehr skalierbar und leistungsfähig erwiesen, umso mehr, als ich jetzt PropertyInfo in PropertyDescriptor umwandle, was mir die gleichen Vorteile von Reflektion mit besserer Leistung bringt. In meiner DAL muss ich einfach schreiben:
%Vor%Alles erzeugt die statische SQL-Klasse, und das macht meinen Code viel einfacher.
Für mich ist der Hauptgrund, dass ich den Zustand dieses DAL-Objekts nicht behalten muss. Der Status der Objekte, die es verwendet, umfasst nicht den Bereich der Methode, die sie eingebettet sind. Auf diese Weise, warum würden Sie mehrere Instanzen eines Objekts behalten, wenn sie alle gleich sind?
Mit den neuesten Versionen von ADO.NET scheint es die beste Vorgehensweise zu sein, die Verbindung zur Datenbank im Rahmen Ihres Aufrufs zu erstellen und zu zerstören, und der ConnectionPool kümmert sich ohnehin um das Problem der Wiederverwendbarkeit der Verbindung.
Auch mit den neuesten Versionen von .NET Framework, TransactionScope (was ein Grund wäre, Ihre Verbindungen selbst zu verwalten), gelangen Sie auf die Geschäftsebene, auf der Sie mehrere Aufrufe an die DAL innerhalb desselben Scope verbinden können.
Ich kann also keinen konkurrierenden Fall sehen, Instanzen des DAL zu erstellen und zu zerstören (oder zwischenzuspeichern).
Tags und Links c# asp.net class-design data-access-layer