Wir stehen am Anfang eines wirklich langen Entwicklungsprojekts mit mehreren Teilprojekten. Grundsätzlich wird jedes Teilprojekt mehrere Monate dauern. Der Code selbst wird in mehrere C # -Projekte aufgeteilt, aber die physische Datenbank wird von allen Projekten gemeinsam genutzt.
Das Problem ist Wartbarkeit. Wenn wir einer Tabelle eine Spalte hinzufügen oder eine Tabelle in zwei kleinere Tabellen aufteilen, müssen wir zurückgehen und unser C # DAL modifizieren, um diese Änderungen zu unterstützen. Dies ist nicht akzeptabel, da wir die DB ständig an die Bedürfnisse des Unternehmens anpassen und nicht nur an die Anforderungen eines einzelnen Programms. Ständig wechselnder alter Code wäre eine unendliche Aufgabe.
Unsere DB-Leute haben eine andere Ansicht vorgeschlagen. Wir machen all unsere CRUD über gespeicherte Prozeduren und verwenden Linq über mehrere Tabellen hinweg, um unsere SELECT-Anweisungen auszuführen. Wenn wir die DB in einigen Jahren neu strukturieren, können wir einfach dieselben gespeicherten Procs und Views bereitstellen und müssen unseren älteren Code nicht ändern.
Die Frage, die wir haben, ist, was ORM sollte für so etwas verwendet werden? EF scheint etwas übertrieben zu sein (vielleicht ist es das nicht). Würde etwas wie SubSonic mit seinem T4 Templating einen simpiler (und vielleicht schneller) DAL ermöglichen?
Oder hat vielleicht jemand eine Idee, wie man diesen ganzen Prozess weniger schmerzhaft machen kann? Wir würden unserer Anwendung lieber keine weitere Ebene hinzufügen, aber wir möchten auch nicht jedes Mal, wenn wir eine Datenbankänderung vornehmen, Code ändern.
Bearbeiten 1: Also als ich sagte "Ich möchte wirklich nicht mehr Schichten hinzufügen". Dies liegt hauptsächlich daran, dass wir bereits mehrere Schichten haben. Wir haben Silverlight-Ansichten, View-Modelle, BLL-Objekte (über CSLA), dann haben wir die DAL und schließlich die SQL-Tabellen selbst.
C# DAL... not just the needs of a single program . Der C # DAL als eine separate Assembly hat den ganzen Sinn, dass es für jede Art von .NET-Anwendung wiederverwendet werden kann. Das Hauptproblem, dem Sie begegnen werden, besteht darin, dass sich die Datenbank ändern muss, wenn die DAL einmal geändert werden muss. Anschließend müssen alle Anwendungen, die von der DAL abhängen, mit der neuen DAL erneut implementiert werden. Sie haben auch das Problem, dass die DAL nicht von Nicht-.NET-Anwendungen verwendet werden kann.
Ok, wie können Sie die DAL so zentralisieren, dass Sie sie nicht für jede Anwendung neu bereitstellen müssen? Denken Sie SOA. Sie können einen WCF-Dienst erstellen, der die DAL (und wahrscheinlich BLL) enthält. Alle Ihre Anwendungen (wenn Sie Webdienste verwenden, auch solche, die nicht .NET sind) können diesen Dienst verwenden. Wenn sich die Datenbank ändert, aktualisieren Sie Ihren WCF-Dienst und stellen ihn einmal bereit. Stellen Sie sicher, dass Sie keine Änderungen vornehmen! Erstellen Sie ein MyMethod2, wenn Sie Funktionalität hinzufügen / ändern müssen.
Hinweis: Wenn Sie n-Tier hören, ist es normalerweise bezieht sich auf drei Ebenen, wo jede Ebene ist eine separate Software und in der Regel auf separate Server: Präsentation (UI), Anwendung (Ihre BLL / DAL), Daten (Ihre SQL-Datenbank). Diese Architektur hat ihren Wert.
We'd rather not add another layer to our application . Ok, also ist Three-Tier möglicherweise nicht der beste Ansatz in Ihrem Fall.
neither do we want to go back and modify code everytime we make a db change Dann ist das, was deine DBA-Leute vorgeschlagen haben, der einzige Weg.
Beachten Sie jedoch Folgendes: Ändert eine gespeicherte Prozedur genauso wie Code geändert wird? Es ist im Grunde dasselbe. Gespeicherte SQL-Prozeduren werden oft nicht versionskontrolliert oder getestet, aber sie sollten es sein. SQL hat nicht den Reichtum einer Sprache wie .NET. WCF kann problemlos in einer Webfarm skaliert werden. Wenn Sie diese und andere Gründe berücksichtigen, kann es sich lohnen, den dreistufigen / SOA-Ansatz zu wählen.
Es hängt wirklich von der Größe Ihres Projekts, den Fähigkeiten der Mitarbeiter, zukünftigem Wachstum usw. ab, und das können Sie nur bestimmen.
Ich habe begonnen, BLToolkit basierend auf den Leistungsdaten von Ссылка zu verwenden
Sie können Ihr Modell in einfachen Klassendateien definieren, einige Methoden mit angewendeten Attributen hinzufügen und Sie haben eine DAL. Teilen Sie eine Tabelle in zwei Teile und Sie können die ursprüngliche Klassendatei beibehalten, während Sie die neuen erstellen, um die geteilten Tabellen zu unterstützen. Stellen Sie nur sicher, dass Sie ein Testprojekt erstellen, das alle Methoden überprüft, um sicherzustellen, dass alle mit jeder Version arbeiten.
Klasse
%Vor%Allgemeine Auswahl- oder Tabellenwertfunktion:
%Vor%Oder um einen gespeicherten proc zu verwenden:
%Vor%Dies ruft die SP DirectoryListing_SelectById
aufOh, und Dinge auf eine klassische Art zu tun, ist auch einfach
%Vor%Das letzte Puzzleteil ist der DB-Manager, der auch LINQ-Unterstützung ermöglicht.
%Vor%Wie lange können Sie ohne die Datenbank arbeiten? Wenn es ein Problem ist, stellen Sie es spät ein. Und ja, das bedeutet wahrscheinlich, dass Sie eine Ebene hinzufügen.
Tags und Links c# entity-framework tsql data-access-layer subsonic3