Ich arbeite in einem Unternehmen, das nur gespeicherte Prozeduren für den gesamten Datenzugriff verwendet, was es sehr ärgerlich macht, unsere lokalen Datenbanken bei jedem Commit, den wir ausführen müssen, synchron zu halten. Ich habe in der Vergangenheit einige grundlegende ORMs verwendet und finde die Erfahrung viel besser und sauberer. Ich möchte dem Entwicklungsleiter und dem Rest des Teams vorschlagen, ein ORM für die zukünftige Entwicklung zu verwenden (der Rest des Teams ist nur mit gespeicherten Prozeduren vertraut und hat noch nie etwas anderes verwendet). Die aktuelle Architektur ist .NET 3.5, geschrieben wie .NET 1.1, mit "God-Klassen", die eine seltsame Implementierung von ActiveRecord verwenden und untypisierte DataSets zurückgeben, die in Code-Behind-Dateien durchlaufen werden. Die Klassen funktionieren ungefähr so:
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...Es gibt so gut wie keine Anwendung von Entwurfsmustern. Es gibt überhaupt keine Tests (niemand weiß, wie man Unit-Tests schreibt, und das Testen erfolgt durch manuelles Laden der Website und Herumstöbern). Durchsuchen Sie unsere Datenbank mit 199 Tabellen, 13 Ansichten, 926 gespeicherten Prozeduren und 93 Funktionen. Ungefähr 30 Tabellen werden für Batch-Jobs oder externe Dinge verwendet, der Rest wird in unserer Kernanwendung verwendet.
Lohnt es sich überhaupt, in diesem Szenario einen anderen Ansatz zu verfolgen? Ich spreche davon, nur voranzukommen, weil wir den vorhandenen Code nicht umgestalten dürfen, da "es funktioniert", sodass wir die vorhandenen Klassen nicht zur Verwendung eines ORM ändern können, aber ich weiß nicht, wie oft wir stattdessen brandneue Module hinzufügen Ich bin mir nicht sicher, ob ein ORM der richtige Ansatz ist (zu viel in gespeicherte Prozeduren und DataSets investiert). Wenn es die richtige Wahl ist, wie soll ich den Fall für die Verwendung einer darstellen? Der einzige Vorteil, den ich mir vorstellen kann, ist, saubereren Code zu haben (auch wenn dies möglicherweise nicht der Fall ist, da die aktuelle Architektur nicht der Fall ist). Ohne Rücksicht auf ORMs würden wir ORMs grundsätzlich auf zukünftige Module ausrichten, aber die alten würden immer noch die DataSets verwenden), und es wäre weniger mühsam, sich daran zu erinnern, welche Prozedurskripte ausgeführt wurden und welche ausgeführt werden müssen. usw. aber das wars auch schon und ich weiß nicht, wie überzeugend ein argument wäre. Die Wartbarkeit ist ein weiteres Problem, das außer mir niemand zu befürchten scheint.