Lavoro in un'azienda che utilizza solo procedure memorizzate per tutti gli accessi ai dati, il che rende molto fastidioso mantenere sincronizzati i nostri database locali poiché ogni impegno 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 ha familiarità solo con le procedure memorizzate e non ha mai usato nient'altro). L'architettura attuale è .NET 3.5 scritta come .NET 1.1, con "classi god" che usano una strana implementazione di ActiveRecord e restituiscono DataSet non tipizzati che sono sottoposti a 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 alcun modello di progettazione. Non ci sono test di sorta (nessun altro sa come scrivere unit test e il test viene effettuato caricando manualmente il sito Web e frugando). 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 cose esterne, 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 ci è permesso di refactoring il codice esistente poiché "funziona", quindi non possiamo cambiare le classi esistenti per usare un ORM, ma non so con quale frequenza invece aggiungiamo moduli nuovi di zecca di aggiungere / correggere i moduli attuali, quindi non sono sicuro che un ORM sia l'approccio giusto (troppo investito in stored procedure e DataSet). Se è la scelta giusta, come devo presentare il caso per usarne uno? Al di fuori della mia testa, l'unico vantaggio che mi viene in mente è avere un codice più pulito (anche se potrebbe non esserlo, dato che l'architettura attuale non costruito con gli ORM in mente, quindi fondamentalmente trufferemmo gli ORM sui moduli futuri, ma i vecchi userebbero comunque i DataSet) e meno problemi per ricordare quali script di procedura sono stati eseguiti e quali devono essere eseguiti, ecc. ma è tutto, e non so quanto sarebbe convincente un argomento. La manutenzione è un'altra preoccupazione, ma di cui nessuno, tranne me, sembra preoccuparsi.