Scrivere il proprio livello di accesso ai dati / mappatura dei dati è una "buona" idea?

Siamo attualmente in una situazione in cui abbiamo una scelta tra utilizzare un mappatore relazionale di oggetti pronto all'uso o implementare il nostro

Abbiamo un'applicazione legacy (ASP.NET + SQL Server) in cui purtroppo il livello dati e il livello aziendale sono uniti. Il sistema non è particolarmente complicato in termini di accesso ai dati. Legge i dati da un grande gruppo (35-40) di tabelle correlate, li manipola in memoria e li salva in alcune altre tabelle in un formato di riepilogo. Ora abbiamo l'opportunità di effettuare il refactoring e stiamo esaminando le tecnologie candidate da utilizzare per separare e strutturare correttamente il nostro accesso ai dati.

Qualunque tecnologia decidiamo, vorremmo:

• hanno oggetti POCO nel nostro modello di dominio che sono ignoranti di persistenza
• avere un livello di astrazione per permetterci di testare gli oggetti del nostro modello di dominio su una sorgente di dati sottostante simulata

Ci sono ovviamente molte cose là fuori già in termini di Patterns & Frameworks ecc.

Personalmente sto spingendo per l'utilizzo di EF insieme al generatore di repository testabile dell'unità ADO.NET / al generatore di entità POCO . Soddisfa tutti i nostri requisiti, può essere facilmente impacchettato all'interno di un modello Repo / UnitOfWork e la nostra struttura DB è ragionevolmente matura (avendo già subito un refactor) in modo tale da non apportare modifiche quotidiane al modello.

Tuttavia, altri nel gruppo stanno suggerendo di progettare / realizzare il nostro DAL completamente da zero. (DataMapper personalizzati, DataContexts, Repository, Interfacce ovunque, Overkill di iniezione di dipendenza per creare oggetti concreti, Traduzione di query LINQ-to-under personalizzate, Implementazioni di cache personalizzate, Implementazioni personalizzate di FetchPlan ...) l'elenco continua ed essere sincero è scioperi io come follia.

Alcuni degli argomenti sollevati sono "Beh, almeno avremo il controllo del nostro codice" o "Oh, ho usato L2S / EF in un progetto precedente e non era altro che mal di testa". (Anche se ho usato entrambi in produzione prima e ho riscontrato che alcuni problemi erano pochi e lontani tra loro e molto gestibili)

Quindi, qualcuna dei tuoi sviluppatori / architetti di grande esperienza là fuori ha qualche parola di saggezza che potrebbe aiutarmi a guidare questo prodotto lontano da quello che mi sembra che sarà un disastro completo. Non posso fare a meno di pensare che qualsiasi vantaggio ottenuto schivando i problemi EF, andrà perso altrettanto rapidamente tentando di reinventare la ruota.

Entrambi gli argomenti con ORM esistenti non sono validi:

"Beh, almeno avremo il controllo del nostro codice"

Perché non scrivere la tua lingua? La tua struttura? Il tuo sistema operativo? E per essere sicuro di avere il controllo di tutto, è anche una buona idea creare il tuo hardware.

"Oh, ho usato L2S / EF in un precedente progetto e non era altro che mal di testa"

EF è abbastanza maturo ed è stato usato con successo da molte persone. Significa che una persona che afferma che l'EF non è altro che un mal di testa dovrebbe probabilmente iniziare a imparare come usare l'EF in modo corretto.

Quindi, devi scrivere il tuo ORM?

Non lo suggerirei. Esistono già ORM di livello professionale, il che significa che devi scrivere i tuoi solo se:

• Hai un contesto preciso in cui tutti gli ORM esistenti non possono adattarsi per qualche motivo,
• Sei sicuro che il costo di creazione e utilizzo del tuo ORM invece di apprenderne uno esistente sia molto più basso. Ciò include il costo del supporto futuro, incluso quello di un altro team di sviluppatori che dovrebbe leggere centinaia di pagine della documentazione tecnica per capire come lavorare con il tuo ORM.

Ovviamente, nulla ti proibisce di scrivere il tuo ORM solo per curiosità, per imparare le cose. Ma non dovresti farlo su un progetto commerciale.

Vedi anche i punti da 2 a 3 della mia risposta alla domanda Reinventare la ruota e NON rimpiangerla. Puoi vedere che i diversi motivi per reinventare la ruota non si applicano qui.

Usa Entity Framework per tutte le cose CRUD ordinarie (dall'80 al 95 percento del codice) e usa il codice di accesso ai dati personalizzato per qualsiasi codice rimanente che deve essere ottimizzato. Questo dovrebbe soddisfare le preoccupazioni di coloro che sostengono che non hai abbastanza controllo.

È una buona idea se e solo se si può essere (almeno ragionevolmente) certi di risparmiare almeno tanto tempo / sforzo scrivendo il proprio codice quanto basta per generare quel codice in primo luogo. A seconda della situazione, ciò potrebbe influire anche sul tuo programma e dovrai tenerne conto. Devi anche considerare la manutenzione a lungo termine nell'equazione. Se ottieni il tuo ORM, dovrai mantenerlo per sempre (o almeno finché lo usi).

La linea di fondo è che può avere senso, nelle giuste condizioni. Queste condizioni generalmente includono:

1. Il progetto a cui stai lavorando è piuttosto grande, quindi il costo è ammortizzato per un grande uso.
2. L'utilizzo dei dati è sufficientemente insolito che le librerie esistenti (e simili) funzionano abbastanza male per i tuoi scopi.

A rischio di affermare l'ovvio, questi due sono in qualche modo collegati inversamente: se stai lavorando a un progetto veramente gigantesco, anche un piccolo risparmio per ogni singolo utilizzo può sommare abbastanza per giustificare lo sviluppo. Al contrario, se le tue esigenze sono davvero insolite, quindi guadagni molto ad ogni utilizzo, il lavoro può essere giustificato anche su un progetto abbastanza piccolo.

Almeno in base alla tua descrizione, tuttavia, nessuno dei due si applica realmente al tuo caso. Forse uno (o entrambi) applicato al precedente uso dell'EF da parte del tuo collega, o forse è solo prevenuto - non credo che tu ci abbia fornito abbastanza informazioni per indovinare persino quale (anche se in tutta onestà, dovrei aggiungere che ' immagino che sia perché non ti ha detto abbastanza da indovinare).

Se fossi responsabile di questa situazione, penso che ognuno di voi scriverà una sorta di position paper - un elenco di punti di forza e di debolezza che vedi con ogni approccio, insieme a prove reali a supporto di ogni asserzione / affermazione /qualunque cosa. L'intero team dovrebbe quindi (cioè essere tenuto a) criticare ogni articolo. Il punto principale nella loro critica sarebbe quello di valutare ogni punto su due scale:

1. il grado in cui il punto sembra preciso, ben supportato da fatti, ecc., e
2. il grado in cui il punto sembra applicarsi al progetto in questione.

Quindi valuterei i documenti e le critiche per giungere a una decisione (anche se essendo del tutto onesto, potrebbe essere difficile dire quanto li stavo usando per prendere la decisione e quanto li stavo usando per giustificare una decisione Avevo già fatto - so che probabilmente non dovrei ammetterlo, ma la realtà è che anch'io sono umano ...)

Modificare:

Se volessi essere particolarmente sgradevole (o "educativo" - difficile dire la differenza in questo caso) vorrei che ognuno di voi tentasse di sviluppare una stima dello sforzo complessivo di sviluppo sia usando un ORM / DAL esistente, sia sviluppando il tuo. Anche se è solo una supposizione, la mia ipotesi immediata è che la maggior parte delle persone con grandi piani per realizzare i propri non si preoccuperebbero di girare le loro stime - al momento in cui hanno elaborato una stima dello sforzo complessivo che era persino finito a distanza (e realistico), si sarebbero resi conto che non c'era modo di avvicinarsi alla competizione con l'uso del codice esistente. Allo stesso tempo, è

Modifica 2: (una specie di suggerimento di @ CmdKey): anche se non esplicitamente menzionato, presumo che una stima includerà implicitamente una valutazione del rischio. In particolare, una stima del tempo dovrebbe normalmente includere numeri in stile PERT:

1. La migliore stima del più veloce potrebbe essere fatta se tutto fosse andato per il verso giusto.
2. La stima "normale": quanto tempo ci si aspetta.
3. La stima del caso peggiore del più lungo che potrebbe richiedere se tutto fosse andato storto.

Naturalmente, le stime del caso migliore e peggiore non dovrebbero normalmente includere cose come l'intervento divino diretto, ma dovrebbero includere quasi tutto ciò che non lo è.

Di solito non è mai una buona idea reinventare la ruota, e farlo di solito è un'indicazione per ignoranza tecnica ("Non conosco nient'altro e non voglio imparare") o arroganza ("X è stupida, posso scrivi il mio strumento tra due settimane! "); Esistono strumenti maturi che possono fare le cose molto meglio di ciò che alcuni sviluppatori medi possono hackerare insieme in poche settimane.

Detto questo, ci sono momenti in cui non è possibile adattare in modo affidabile un'applicazione legacy attorno a una soluzione esistente (non importa quanto sia flessibile) senza un sacco di lavoro; in un caso come questo non è una "buona" idea, ma un'idea migliore delle alternative (cioè lasciarla così com'è, o riscriverne metà per poter usare il livello di terze parti) in modo da avere poca scelta.

Ero su un progetto che ha rifiutato gli strumenti Java ORM esistenti di scrivere i propri, a causa di alcune funzionalità "critiche" che non erano presenti in Hibernate. Questo è stato un errore da molti milioni di dollari e il costo è in aumento ogni giorno. Non hanno ancora pieno supporto per le relazioni oggettuali. Quindi, oltre a tutto il tempo speso a creare e mantenere il framework, stanno trascorrendo ore a scrivere codice che potrebbe essere scritto in pochi minuti usando Hibernate, o in molti casi non dovrebbe essere affatto scritto.

I quadri esistenti sono il prodotto di decine di anni-uomo di sforzi. È assurdamente ingenuo immaginare che una sola squadra potrebbe avvicinarsi da qualche parte in poche settimane.

Il codice che devi scrivere è il codice che devi mantenere. Il tempo impiegato a mantenere il codice ORM è il tempo impiegato a non mantenere l'app. A meno che l'ORM non offra un qualche tipo di vantaggio strategico, allora non è qualcosa che genererà denaro per l'azienda, quindi è puro sovraccarico. La tua azienda preferirebbe spendere soldi per spese generali o per migliorare un prodotto redditizio? Se questo è per un'app interna, potrebbe trattarsi di un problema, ma stai ancora aumentando la quantità di codice che dovrà essere scritto, testato e documentato.

Direi che lanciare il tuo ORM è un'idea MALE - a meno che tu non abbia una ragione molto, molto buona per farlo (tra l'altro, quelli che hai citato non sono abbastanza buoni :)

Una volta ho fatto un errore nel convincere gli altri a convincermi a non usare ORM e posso dirti che scrivere tutto il DAL da soli ci ha davvero rallentato e invece di implementare funzionalità che contavano per il business stavamo trascorrendo del tempo su DAL (è molto più lavoro di quanto sembri).

I nuovi EF EF saranno piuttosto buoni, ma se vuoi un maggiore controllo - mi sarei dato un'occhiata a micro ORM / s come: Drapper http://code.google.com/p/dapper-dot-net/ o PetaPOCO http : //www.toptensoftware.com/petapoco/

Puoi anche mescolare e abbinare - usa EF per la maggior parte delle cose e Drapper per qualche messa a punto.

Comunque è solo il mio 2c;)