La scrittura del proprio Data Access / Data Mapping Layer è un'idea "buona"?

Entrambi gli argomenti contro gli ORM esistenti non sono validi:

"Well at least we'll be in control of our own code"

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 I've used L2S/EF in a previous project and it was nothing but headaches"

EF è abbastanza maturo ed è stato utilizzato con successo da molte persone. Significa che una persona che afferma che EF non è altro che un mal di testa dovrebbe probabilmente iniziare a imparare come utilizzare correttamente EF.

Quindi, devi scrivere il tuo ORM?

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

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

Naturalmente, nulla ti vieta 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 di la mia risposta alla domanda Reinventare la ruota e NON rimpiangerla. Puoi vedere che i diversi motivi per reinventare la ruota non si applicano qui.

Utilizza Entity Framework per tutti gli elementi ordinari di CRUD (dall'80 al 95 percento del codice) e utilizza il codice di accesso ai dati personalizzato per qualsiasi codice rimanente che deve essere ottimizzato. Questo dovrebbe soddisfare preoccupazioni di coloro che sostengono che non si ha abbastanza controllo.

È una buona idea se e solo se puoi essere (almeno ragionevolmente) certo che risparmierai almeno tanto tempo / impegno scrivendo il tuo codice come necessario per generare quel codice in primo luogo. A seconda della situazione, ciò potrebbe anche influire sul tuo programma e dovrai farlo anche in questo caso. Devi anche considerare la manutenzione a lungo termine nell'equazione. Se arrotoli il tuo ORM, dovrai mantenerlo per sempre (o almeno finché lo usi).

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

1. Il progetto su cui stai lavorando è abbastanza grande, quindi il costo viene ammortizzato su una grande quantità di utilizzo.
2. L'uso dei tuoi dati è sufficientemente inusuale che le librerie esistenti (e simili) funzionano in modo piuttosto scadente per i tuoi scopi.

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

Almeno in base alla descrizione, tuttavia, non si applica veramente nel tuo caso. Forse uno (o anche entrambi) si è applicato al precedente utilizzo di EF da parte dei tuoi colleghi, o forse è solo prevenuto - Non penso che tu ci abbia dato abbastanza informazioni per indovinare anche quale (anche se in tutta onestà, dovrei aggiungere che io " Suppongo che sia perché non ti ha detto abbastanza per indovinare)

Se ero a capo di questa situazione, penso che vorrei che tu e i tuoi colleghi scriviate una sorta di position paper, una lista di punti di forza e di debolezza che vedete con ogni approccio, insieme a prove reali a sostegno di ciascuna asserzione / reclamo / qualunque cosa. L'intera squadra avrebbe quindi dovuto (cioè, sarebbe stato necessario) criticare ogni articolo. Il punto principale della loro critica sarebbe valutare ogni punto su due scale:

1. il grado in cui il punto sembra accurato, ben supportato da fatti, ecc. e
2. il grado in cui sembra che il punto si applichi al progetto a portata di mano.

Quindi valuterei i documenti e le critiche per arrivare a una decisione (sebbene fosse del tutto onesto, potrebbe essere difficile dire quanto li stavo usando per prendere la decisione, e quanto li stavo usando per giustifica una decisione che avevo già preso - so che probabilmente non dovrei ammetterlo, ma la realtà è che anch'io sono umano ...)

Modifica:

Se volessi essere particolarmente cattivo (o "educativo", difficile da dire in questo caso), vorrei che ognuno di voi tentasse di sviluppare una stima dello sforzo di sviluppo complessivo sia usando un ORM / DAL esistente e sviluppando il tuo. Anche se è solo un'ipotesi, la mia ipotesi immediata è che la maggior parte delle persone che hanno grandi piani per la propria laminazione non si preoccuperebbero di trasformare le loro stime - nel momento in cui hanno escogitato una stima dello sforzo complessivo che è stato persino completato da remoto (e realistico), si sarebbero resi conto che non c'era modo di avvicinarsi alla competizione con l'uso del codice esistente. Allo stesso tempo, è sempre possibile che qualcuno arrivi a qualcosa di sufficientemente ragionevole da valere la pena di considerarlo e persino utilizzarlo, specialmente se (per esempio) hanno lavorato a una sorta di miglioramento / massaggio di uno strumento / framework esistente di rotolare il proprio da zero.

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

1. La stima migliore del più veloce potrebbe essere eseguita se tutto è andato bene.
2. La stima "normale" - quanto tempo ti aspetti che prenda.
3. La stima peggiore del tempo più lungo che potrebbe richiedere se tutto è andato storto.

Ovviamente, le stime dei casi migliori e peggiori non dovrebbero normalmente includere cose come un intervento diretto divino, ma dovrebbero includere qualsiasi cosa a parte.

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

Tuttavia, ci sono momenti in cui non è possibile installare in modo affidabile un'applicazione legacy attorno a una soluzione esistente (indipendentemente da quanto sia flessibile) senza un sacco di lavoro; in un caso come questo non è un'idea "buona", ma un'idea migliore delle alternative (es. lasciandola così com'è o riscrivendone metà per poter usare il livello di terze parti) quindi non hai scelta.

Ero in un progetto che rifiutava gli strumenti Java ORM esistenti per scrivere il proprio, 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 tra oggetti. Quindi, oltre a tutto il tempo speso per creare e mantenere il framework, stanno passando ore a scrivere codice che potrebbe essere scritto in pochi minuti usando Hibernate, o in molti casi non avrebbe bisogno di essere scritto affatto.

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

Il codice che devi scrivere è il codice che devi mantenere. Il tempo impiegato a mantenere il codice ORM è il tempo impiegato a non a mantenere l'app. A meno che l'ORM non ti dia qualche tipo di vantaggio strategico, allora non è qualcosa che genererà soldi per il business, quindi è un overhead puro. La tua azienda preferirebbe spendere soldi in spese generali o migliorare un prodotto che guadagna soldi? Se questo è per un'app interna, potrebbe trattarsi di un problema, ma stai ancora aumentando la quantità di codice che dovrà essere scritta, testata e documentata.

Direi che implementare il tuo ORM è un'idea BAD - a meno che tu non abbia una ragione molto, molto divina per farlo (btw quelli che hai citato non sono abbastanza buoni:)

Ho fatto un errore una volta che gli altri mi hanno convinto a non usare ORM e posso dirti che scrivere tutto il DAL ci ha davvero rallentato e invece di implementare funzionalità che contavano per il business stavamo spendendo del tempo su DAL (è un molto più lavoro di quello che sembra).

I nuovi EF sem devono essere abbastanza buoni, ma se vuoi avere un maggiore controllo - mi piacerebbe dare un'occhiata a micro ORM / s come: Drapper link o PetaPOCO link

Puoi anche mescolare e abbinare: usa EF per la maggior parte delle cose e Drapper per alcune regolazioni fini.

Comunque è solo il mio 2c;)