Pracuję w firmie, która korzysta z procedur przechowywanych tylko dla wszystkich danych, co sprawia, że bardzo denerwujące jest utrzymywanie synchronizacji naszych lokalnych baz danych, ponieważ każde zatwierdzenie musimy uruchamiać nowe procesy. W przeszłości korzystałem z podstawowych ORM i uważam, że doświadczenie jest znacznie lepsze i czystsze. Chciałbym zasugerować kierownikowi ds. Rozwoju i reszcie zespołu, że rozważamy użycie pewnego rodzaju ORM do przyszłego rozwoju (reszta zespołu zna tylko procedury składowane i nigdy nie używała niczego innego). Obecna architektura to .NET 3.5 napisany jak .NET 1.1, z „boskimi klasami”, które używają dziwnej implementacji ActiveRecord i zwracają nietypowe zestawy danych, które są zapętlone w plikach za kodem - klasy działają mniej więcej tak:
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...
Prawie nie ma zastosowania żadnych wzorców projektowych. Nie ma żadnych testów (nikt inny nie wie, jak pisać testy jednostkowe, a testowanie odbywa się poprzez ręczne załadowanie strony internetowej i przeglądanie). Przeglądając naszą bazę danych mamy: 199 tabel, 13 widoków, aż 926 procedur przechowywanych i 93 funkcje. Około 30 tabel jest używanych do zadań wsadowych lub rzeczy zewnętrznych, pozostałe są używane w naszej podstawowej aplikacji.
Czy w tym scenariuszu warto w ogóle zastosować inne podejście? Mówię o posunięciu się naprzód tylko dlatego, że nie wolno nam refaktoryzować istniejącego kodu, ponieważ „działa”, więc nie możemy zmienić istniejących klas na użycie ORM, ale nie wiem, jak często dodajemy nowe moduły zamiast tego dodawania / naprawy bieżących modułów, więc nie jestem pewien, czy ORM jest właściwym podejściem (zbyt dużo zainwestowanych w procedury składowane i DataSets). Jeśli jest to właściwy wybór, jak mam przedstawić przypadek użycia takiego? Z mojej głowy jedyne korzyści, jakie mogę wymyślić, to czystszy kod (choć może nie być, ponieważ obecna architektura nie jest t zbudowany z myślą o ORM, abyśmy mogli w zasadzie sforsować ORMy w przyszłych modułach, ale stare nadal będą korzystać z DataSets) i mniej kłopotów, aby pamiętać, jakie skrypty procedur zostały uruchomione, a które należy uruchomić, itd., ale o to chodzi i nie wiem, jak przekonujący byłby to argument. Utrzymanie jest kolejnym problemem, ale wydaje się, że nikt poza mną nie martwi się.