Lavoro in un'azienda che utilizza solo stored procedure per l'accesso a tutti i dati, il che rende molto fastidioso mantenere sincronizzati i nostri database locali come ogni commit che abbiamo per eseguire nuovi proc. Ho usato alcuni ORM di base in passato e trovo l'esperienza molto migliore e più pulita. Vorrei suggerire al responsabile dello sviluppo e al resto del team che esamineremo l'utilizzo di un ORM di qualche tipo per lo sviluppo futuro (il resto del team conosce solo le stored procedure e non ha mai usato altro). L'architettura attuale è .NET 3.5 scritta come .NET 1.1, con "divinità" che usano una strana implementazione di ActiveRecord e restituiscono DataSet non tipizzati che sono collegati in loop in file code-behind - le classi funzionano in questo modo:
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...
Non c'è praticamente nessuna applicazione di nessun modello di design. Non ci sono test di sorta (nessun altro sa come scrivere test unitari, e il test viene eseguito caricando manualmente il sito Web e scorrendo). Guardando attraverso il nostro database abbiamo: 199 tabelle, 13 viste, un enorme 926 stored procedure e 93 funzioni. Circa 30 tabelle vengono utilizzate per lavori batch o esterni, il resto viene utilizzato nella nostra applicazione principale.
Vale la pena perseguire un approccio diverso in questo scenario? Sto parlando di andare avanti solo perché non siamo autorizzati a rifattorizzare il codice esistente poiché "funziona", quindi non possiamo cambiare le classi esistenti per usare un ORM, ma non so quanto spesso aggiungiamo moduli nuovi di zecca di aggiungere / correggere i moduli correnti quindi non sono sicuro che un ORM sia l'approccio giusto (troppo investito nelle stored procedure e nei DataSet). Se è la scelta giusta, come dovrei presentare il caso per l'utilizzo di uno? Al di sopra della mia testa gli unici benefici che posso pensare è avere un codice più pulito (anche se potrebbe non esserlo, dato che l'architettura attuale non è costruita con gli ORM in mente quindi dovremmo fondamentalmente fare il montaggio della giurisprudenza su moduli futuri ma i vecchi continuerebbero a utilizzare i DataSet) e meno problemi a ricordare quale script di procedura è stato eseguito e quali devono essere eseguiti, ecc. ma questo è tutto, e non so quanto sarebbe convincente un argomento. La manutenibilità è un'altra preoccupazione ma una che nessuno tranne me sembra preoccuparsi.