Ci sono buoni motivi per non utilizzare un ORM? [chiuso]

Durante il mio apprendistato, ho utilizzato NHibernate per alcuni progetti più piccoli che ho principalmente codificato e progettato da solo. Ora, prima di iniziare un progetto più grande, è nata la discussione su come progettare l'accesso ai dati e se utilizzare o meno un livello ORM. Dato che sono ancora nel mio apprendistato e mi considero ancora un principiante nella programmazione aziendale, non ho davvero provato a spingere secondo me, che è che l'uso di un mappatore relazionale a oggetti per il database può facilitare molto lo sviluppo. Gli altri programmatori del team di sviluppo sono molto più esperti di me, quindi penso che farò solo quello che dicono. :-)

Tuttavia, non capisco completamente due dei motivi principali per non utilizzare NHibernate o un progetto simile:

1. Si può semplicemente creare i propri oggetti di accesso ai dati con query SQL e copiare tali query da Microsoft SQL Server Management Studio.
2. Il debug di un ORM può essere difficile.

Quindi, ovviamente potrei semplicemente costruire il mio livello di accesso ai dati con molti SELECTs ecc., Ma qui mi manca il vantaggio dei join automatici, delle classi proxy a caricamento lento e di uno sforzo di manutenzione inferiore se una tabella ottiene una nuova colonna o una colonna ottiene rinominato. (Aggiornamento numerosi SELECT, INSERTe UPDATEle query contro l'aggiornamento del config mappatura ed eventualmente refactoring le classi business e DTOs.)

Inoltre, usando NHibernate puoi incorrere in problemi imprevisti se non conosci molto bene il framework. Ciò potrebbe essere, ad esempio, fidarsi di Table.hbm.xml in cui si imposta la lunghezza di una stringa da convalidare automaticamente. Tuttavia, posso anche immaginare bug simili in un "semplice" livello di accesso ai dati basato su query SqlConnection.

Infine, gli argomenti sopra menzionati sono davvero un buon motivo per non utilizzare un ORM per un'applicazione aziendale basata su database non banale? Probabilmente ci sono altri argomenti che potrebbero essersi persi?

(Probabilmente dovrei aggiungere che penso che questa sia come la prima "grande" applicazione basata su .NET / C # che richiederà il lavoro di squadra. Le buone pratiche, che sono viste come abbastanza normali su Stack Overflow, come il test di unità o l'integrazione continua, non sono -esistenti qui fino ad ora.)

Negli ultimi anni c'è stata un'esplosione di crescita con gli ORM ei tuoi colleghi più esperti potrebbero ancora pensare nella mentalità "ogni chiamata al database dovrebbe avvenire attraverso una procedura memorizzata".

Perché un ORM dovrebbe rendere le cose più difficili da eseguire il debug? Otterrai lo stesso risultato indipendentemente dal fatto che provenga da una procedura memorizzata o dall'ORM.

Immagino che l'unico vero svantaggio a cui posso pensare con un ORM sia che il modello di sicurezza è un po 'meno flessibile.

EDIT: ho appena riletto la tua domanda e sembra che stiano copiando e incollando le query in sql inline. Ciò rende il modello di sicurezza uguale a un ORM, quindi non ci sarebbe assolutamente alcun vantaggio su questo approccio rispetto a un ORM. Se utilizzano query non parametrizzate, sarebbe effettivamente un rischio per la sicurezza.

La risposta breve è sì, ci sono davvero buone ragioni. È un dato di fatto che ci sono casi in cui non è possibile utilizzare un ORM.

Caso in questione, lavoro per una grande istituzione finanziaria aziendale e dobbiamo seguire molte linee guida sulla sicurezza. Per soddisfare le regole e le normative che ci vengono imposte, l'unico modo per superare i controlli è mantenere l'accesso ai dati all'interno delle procedure memorizzate. Alcuni potrebbero dire che è semplicemente stupido, ma onestamente non lo è. L'uso di uno strumento ORM significa che lo strumento / sviluppatore può inserire, selezionare, aggiornare o eliminare ciò che desidera. Le stored procedure forniscono molta più sicurezza, specialmente negli ambienti quando si tratta di dati del cliente. Penso che questo sia il motivo principale da considerare. Sicurezza.

Il punto debole degli ORM

Gli ORM sono utili per automatizzare il 95% + delle query laddove applicabili. Il loro punto di forza è quando si dispone di un'applicazione con una forte architettura del modello a oggetti e un database che funziona bene con quel modello a oggetti. Se stai realizzando una nuova build e hai forti capacità di modellazione nel tuo team, probabilmente otterrai buoni risultati con un ORM.

Potresti avere una manciata di domande che è meglio fare a mano. In questo caso, non aver paura di scrivere alcune stored procedure per gestirlo. Anche se intendi trasferire la tua app su più piattaforme DBMS, il codice dipendente dal database sarà in minoranza. Tenendo presente che dovrai testare la tua applicazione su qualsiasi piattaforma su cui intendi supportarla, un po 'di sforzo extra di porting per alcune stored procedure non farà molta differenza per il tuo TCO. Per una prima approssimazione, il 98% di portabilità è altrettanto buono del 100% di portabilità e di gran lunga migliore delle soluzioni contorte o con prestazioni scarse per aggirare i limiti di un ORM.

Ho visto il primo approccio funzionare bene su un progetto J2EE molto ampio (100 anni di personale).

Dove un ORM potrebbe non essere la soluzione migliore

In altri casi potrebbero esserci approcci che si adattano all'applicazione meglio di un ORM. Patterns of Enterprise Application Architecture di Fowler ha una sezione sui modelli di accesso ai dati che fa un buon lavoro di catalogazione di vari approcci a questo. Alcuni esempi che ho visto di situazioni in cui un ORM potrebbe non essere applicabile sono:

• Su un'applicazione con una base di codice legacy sostanziale di stored procedure, è possibile utilizzare un livello di accesso ai dati orientato alla funzionalità (da non confondere con i linguaggi funzionali) per eseguire il wrapping delle attività principali. Ciò riutilizza il livello di accesso ai dati e la progettazione del database esistenti (e quindi testati e sottoposti a debug), che spesso rappresenta uno sforzo di sviluppo e test piuttosto sostanziale e consente di risparmiare sulla migrazione dei dati a un nuovo modello di database. Spesso è un buon modo per avvolgere i livelli Java attorno a basi di codice PL / SQL legacy o reindirizzare le app rich client VB, Powerbuilder o Delphi con interfacce web.

• Una variazione è dove erediti un modello di dati che non è necessariamente adatto alla mappatura OR. Se (ad esempio) si sta scrivendo un'interfaccia che popola o estrae dati da un'interfaccia esterna, potrebbe essere meglio lavorare direttamente con il database.

• Applicazioni finanziarie o altri tipi di sistemi in cui l'integrità dei dati tra sistemi è importante, in particolare se si utilizzano transazioni distribuite complesse con commit in due fasi. Potrebbe essere necessario microgestire le transazioni meglio di quanto un ORM sia in grado di supportare.

• Applicazioni ad alte prestazioni in cui desideri ottimizzare l'accesso al database. In questo caso, potrebbe essere preferibile lavorare a un livello inferiore.

• Situazioni in cui stai utilizzando un meccanismo di accesso ai dati esistente come ADO.Net che è "abbastanza buono" e giocare bene con la piattaforma è di maggiore vantaggio rispetto a ORM.

• A volte i dati sono solo dati: può essere il caso (ad esempio) che la tua applicazione stia lavorando con "transazioni" piuttosto che con "oggetti" e che questa sia una visione ragionevole del dominio. Un esempio potrebbe essere un pacchetto finanziario in cui hai transazioni con campi di analisi configurabili. Sebbene l'applicazione stessa possa essere costruita su una piattaforma OO, non è legata a un singolo modello di dominio aziendale e potrebbe non essere a conoscenza di molto di più di codici GL, account, tipi di documenti e mezza dozzina di campi di analisi. In questo caso l'applicazione non è a conoscenza di un modello di dominio aziendale in quanto tale e un modello a oggetti (oltre la struttura del registro stesso) non è rilevante per l'applicazione.

Prima di tutto: l'utilizzo di un ORM non renderà il tuo codice più facile da testare, né fornirà necessariamente alcun vantaggio in uno scenario di integrazione continua.

Nella mia esperienza, mentre l'utilizzo di un ORM può aumentare la velocità di sviluppo, i problemi più grandi che devi affrontare sono:

1. Testare il codice
2. Mantenere il codice

Le soluzioni a questi sono:

1. Rendi il tuo codice testabile (utilizzando i principi SOLID )
2. Scrivi test automatizzati per la maggior parte del codice possibile
3. Esegui i test automatizzati il ​​più spesso possibile

Venendo alla tua domanda, le due obiezioni che elenchi sembrano più ignoranza che altro.

Non essere in grado di scrivere query SELECT a mano (che, presumo, è il motivo per cui è necessario il copia-incolla) sembra indicare che c'è un'urgente necessità di un po 'di formazione SQL.

Ci sono due ragioni per cui non userei un ORM:

1. È severamente vietato dalla politica dell'azienda (nel qual caso andrei a lavorare da qualche altra parte)
2. Il progetto è estremamente intensivo di dati e l'utilizzo di soluzioni specifiche del fornitore (come BulkInsert) ha più senso.

I soliti respingimenti sugli ORM (NHibernate in particolare) sono:

1. Velocità

   Non c'è motivo per cui l'utilizzo di un ORM sarebbe più lento dell'accesso ai dati codificato a mano. In effetti, grazie alla memorizzazione nella cache e alle ottimizzazioni incorporate, può essere più veloce. Un buon ORM produrrà una serie ripetibile di query per le quali è possibile ottimizzare il proprio schema. Un buon ORM consentirà anche un recupero efficiente dei dati associati utilizzando varie strategie di recupero.

2. Complessità

   Per quanto riguarda la complessità, l'utilizzo di un ORM significa meno codice, che generalmente significa meno complessità. Molte persone che utilizzano l'accesso ai dati scritto a mano (o generato da codice) si trovano a scrivere il proprio framework su librerie di accesso ai dati "di basso livello" (come la scrittura di metodi di supporto per ADO.Net). Questi equivalgono a una maggiore complessità e, peggio ancora, sono raramente ben documentati o ben testati.
   Se stai guardando specificamente NHibernate, anche strumenti come Fluent NHibernate e Linq To NHibernate ammorbidiscono la curva di apprendimento.

La cosa che mi colpisce dell'intero dibattito ORM è che le stesse persone che affermano che l'uso di un ORM sarà troppo difficile / lento / qualunque siano le stesse persone che sono più che felici di usare Linq To Sql o i set di dati tipizzati. Sebbene Linq To Sql sia un grande passo nella giusta direzione, sono ancora anni luce indietro rispetto a dove si trovano alcuni ORM open source. Tuttavia, i framework sia per i set di dati tipizzati che per Linq To Sql sono ancora estremamente complessi e utilizzarli per andare troppo oltre (Tabella = Classe) + (CRUD di base) è stupidamente difficile.

Il mio consiglio è che se, alla fine della giornata, non riesci a ottenere un ORM, assicurati che l'accesso ai tuoi dati sia separato dal resto del codice e di seguire il consiglio di codifica della Gang Of Four un'interfaccia. Inoltre, procurati un framework Dependancy Injection per eseguire il cablaggio.

(Che ne dici di uno sfogo?)

Esistono una vasta gamma di problemi comuni per i quali gli strumenti ORM come Hibernate sono un invio divino e alcuni in cui è un ostacolo. Non so abbastanza del tuo progetto per sapere qual è.

Uno dei punti di forza di Hibernate è che puoi dire le cose solo 3 volte: ogni proprietà è menzionata nella classe, nel file .hbm.xml e nel database. Con le query SQL, le tue proprietà sono nella classe, nel database, nelle istruzioni select, nelle istruzioni insert, nelle istruzioni update, nelle istruzioni delete e in tutto il codice di marshalling e unmarshalling che supporta le tue query SQL! Questo può diventare disordinato velocemente. D'altra parte, sai come funziona. Puoi eseguirne il debug. Va tutto bene nel tuo livello di persistenza, non sepolto nelle viscere di uno strumento di terze parti.

Hibernate potrebbe essere un poster-bambino per la legge di Leaky Abstractions di Spolsky. Allontanati un po 'dai sentieri battuti e devi conoscere il funzionamento interno profondo dello strumento. Può essere molto fastidioso quando sai che avresti potuto correggere l'SQL in pochi minuti, ma invece passi ore a cercare di convincere il tuo strumento Dang a generare un SQL ragionevole. Il debugging a volte è un incubo, ma è difficile convincere le persone che non ci sono state.

EDIT: Potresti voler esaminare iBatis.NET se non verranno girati su NHibernate e vogliono il controllo sulle loro query SQL.

EDIT 2: Ecco la grande bandiera rossa, però: "Le buone pratiche, che sono viste come abbastanza normali su Stack Overflow, come i test di unità o l'integrazione continua, non esistono qui fino ad ora." Quindi, questi sviluppatori "esperti", che esperienza hanno nello sviluppo? La loro sicurezza sul lavoro? Sembra che tu possa essere tra persone che non sono particolarmente interessate al campo, quindi non lasciare che uccidano il tuo interesse. Devi essere l'equilibrio. Combatti.

Ho lavorato a un progetto in cui il mancato utilizzo di un ORM ha avuto molto successo. Era un progetto quello

1. Doveva essere scalato orizzontalmente dall'inizio
2. Doveva essere sviluppato rapidamente
3. Aveva un modello di dominio relativamente semplice

Il tempo che sarebbe stato necessario per far funzionare NHibernate in una struttura partizionata orizzontalmente sarebbe stato molto più lungo del tempo necessario per sviluppare un semplicissimo datamapper che fosse a conoscenza del nostro schema di partizionamento ...

Quindi, nel 90% dei progetti a cui ho lavorato su un ORM è stato un aiuto inestimabile. Ma ci sono alcune circostanze molto specifiche in cui vedo che non usare un ORM è il migliore.

Permettetemi innanzitutto di dire che gli ORM possono semplificare la vostra vita di sviluppo se integrati correttamente, ma ci sono una manciata di problemi in cui l'ORM può effettivamente impedirvi di raggiungere i requisiti e gli obiettivi dichiarati.

Ho scoperto che quando si progettano sistemi con requisiti di prestazioni elevati, spesso sono sfidato a trovare modi per rendere il sistema più performante. Molte volte, mi ritrovo con una soluzione che ha un profilo di prestazioni di scrittura pesante (il che significa che stiamo scrivendo dati molto più di quanto stiamo leggendo dati). In questi casi, voglio sfruttare le funzionalità che la piattaforma database mi offre per raggiungere i nostri obiettivi di prestazioni (è OLTP, non OLAP). Quindi, se sto usando SQL Server e so di avere molti dati da scrivere, perché non dovrei usare un inserimento in blocco ... beh, come potresti aver già scoperto, la maggior parte degli ORMS (non so se anche uno solo lo fa) non hanno la capacità di sfruttare i vantaggi specifici della piattaforma come l'inserimento in blocco.

Dovresti sapere che puoi unire le tecniche ORM e non ORM. Ho appena scoperto che ci sono una manciata di casi limite in cui gli ORM non possono supportare le tue esigenze e devi aggirarli per quei casi.

Quando è necessario aggiornare 50000000 record. Imposta una bandiera o qualsiasi altra cosa.

Prova a farlo utilizzando un ORM senza chiamare una stored procedure o comandi SQL nativi.

Aggiornamento 1: prova anche a recuperare un record con solo alcuni dei suoi campi. (Quando hai un tavolo molto "largo"). O un risultato scalare. Gli ORM fanno schifo anche in questo.

AGGIORNAMENTO 2 : Sembra che EF 5.0 beta prometta aggiornamenti in batch, ma questa è una notizia molto calda (2012, gennaio)

Per un'applicazione aziendale basata su database non banale, non c'è davvero alcuna giustificazione per non utilizzare un ORM.

Caratteristiche a parte:

• Non utilizzando un ORM, stai risolvendo un problema che è già stato risolto ripetutamente da grandi comunità o aziende con risorse significative.
• Utilizzando un ORM, l'elemento centrale del livello di accesso ai dati beneficia degli sforzi di debug di quella comunità o azienda.

Per dare una prospettiva all'argomento, considera i vantaggi dell'utilizzo di ADO.NET rispetto alla scrittura del codice per analizzare autonomamente il flusso di dati tabulari.

Ho visto che l'ignoranza su come utilizzare un ORM giustifica il disprezzo di uno sviluppatore per gli ORM Ad esempio: caricamento desideroso (qualcosa che ho notato che non hai menzionato). Immagina di voler recuperare un cliente e tutti i suoi ordini e per questi tutti gli articoli dei dettagli dell'ordine. Se ti affidi solo al caricamento lento, ti allontanerai dalla tua esperienza ORM con l'opinione: "Gli ORM sono lenti". Se impari a usare il caricamento ansioso, lo farai in 2 minuti con 5 righe di codice, ciò che i tuoi colleghi impiegheranno mezza giornata per implementare: una query al database e associare i risultati a una gerarchia di oggetti. Un altro esempio potrebbe essere il dolore di scrivere manualmente query SQL per implementare il paging.

La possibile eccezione all'utilizzo di un ORM sarebbe se tale applicazione fosse un framework ORM progettato per applicare astrazioni di logica aziendale specializzate e progettato per essere riutilizzato su più progetti. Anche se così fosse, tuttavia, si otterrebbe un'adozione più rapida migliorando un ORM esistente con quelle astrazioni.

Non lasciare che l'esperienza dei membri del tuo team senior ti trascini nella direzione opposta rispetto all'evoluzione dell'informatica. Mi sto sviluppando professionalmente da 23 anni e una delle costanti è il disprezzo per il nuovo da parte della vecchia scuola. Gli ORM sono per SQL come il linguaggio C era per l'assembly e puoi scommettere che gli equivalenti a C ++ e C # sono in arrivo. Una riga di codice new-school equivale a 20 righe di codice old-school.

Penso che forse quando lavori su sistemi più grandi puoi usare uno strumento di generatore di codice come CodeSmith invece di un ORM ... Recentemente ho trovato questo: Cooperator Framework che genera procedure archiviate di SQL Server e genera anche entità aziendali, mappatori, gateway, lazyload e tutta quella roba in C # ... dai un'occhiata ... è stato scritto da un team qui in Argentina ...

Penso che sia nel mezzo tra la codifica dell'intero livello di accesso ai dati e l'utilizzo di un ORM ...

Personalmente, mi sono opposto (fino a poco tempo fa) all'uso di un ORM e sono solito cavarmela scrivendo un livello di accesso ai dati che incapsula tutti i comandi SQL. L'obiezione principale agli ORM era che non mi fidavo dell'implementazione ORM per scrivere esattamente l'SQL corretto. E, a giudicare dagli ORM che vedevo (principalmente librerie PHP), penso di aver assolutamente ragione.

Ora, la maggior parte del mio sviluppo web utilizza Django e ho trovato l'ORM incluso davvero conveniente, e poiché il modello di dati è espresso prima nei loro termini e solo successivamente in SQL, funziona perfettamente per le mie esigenze. Sono sicuro che non sarebbe troppo difficile superarlo e sarà necessario integrarlo con SQL scritto a mano; ma per CRUD l'accesso è più che sufficiente.

Non so di NHibernate; ma immagino che sia anche "abbastanza buono" per la maggior parte di ciò di cui hai bisogno. Ma se altri programmatori non si fidano di esso; sarà il principale sospettato di ogni bug relativo ai dati, rendendo la verifica più noiosa.

Potresti provare a introdurlo gradualmente nel tuo posto di lavoro, concentrandoti prima su piccole applicazioni "ovvie", come il semplice accesso ai dati. Dopo un po ', potrebbe essere utilizzato su prototipi e potrebbe non essere sostituito ...

Se si tratta di un database OLAP (ad es. Dati statici di sola lettura utilizzati per la creazione di report / analisi, ecc.), L'implementazione di un framework ORM non è appropriata. Sarebbe invece preferibile utilizzare la funzionalità di accesso ai dati nativa del database come le stored procedure. Gli ORM sono più adatti per i sistemi transazionali (OLTP).

Penso che ci siano molti buoni motivi per non utilizzare un ORM. Innanzitutto, sono uno sviluppatore .NET e mi piace restare fedele a ciò che il meraviglioso framework .NET mi ha già fornito. Fa tutto ciò di cui ho bisogno. In questo modo, mantieni un approccio più standard, e quindi ci sono molte più possibilità che qualsiasi altro sviluppatore che lavora allo stesso progetto lungo la strada sia in grado di raccogliere ciò che c'è e correre con esso. Le capacità di accesso ai dati già fornite da Microsoft sono abbastanza ampie, non c'è motivo di scartarle.

Sono uno sviluppatore professionista da 10 anni, conduco più progetti di grande successo da un milione di dollari e non ho mai scritto un'applicazione che doveva essere in grado di passare a qualsiasi database. Perché mai vorresti che un cliente lo facesse? Pianifica attentamente, scegli il database giusto per ciò di cui hai bisogno e mantienilo. Personalmente SQL Server è stato in grado di fare qualsiasi cosa io abbia mai avuto bisogno di fare. È facile e funziona alla grande. C'è anche una versione gratuita che supporta fino a 10 GB di dati. Oh, e funziona alla grande con .NET.

Recentemente ho dovuto iniziare a lavorare su diversi progetti che utilizzano un ORM come datalayer. Penso che sia brutto e qualcosa in più che ho dovuto imparare a usare senza motivo. Nella circostanza follemente rara in cui il cliente aveva bisogno di cambiare database, avrei potuto facilmente rielaborare l'intero datalayer in meno tempo di quanto ho speso a scherzare con i fornitori di ORM.

Onestamente, penso che ci sia un vero utilizzo per un ORM: se stai creando un'applicazione come SAP che ha davvero bisogno della capacità di essere eseguita su più database. In caso contrario, come fornitore di soluzioni, dico ai miei clienti che questa applicazione è progettata per funzionare su questo database ed è così. Ancora una volta, dopo 10 anni e innumerevoli applicazioni, questo non è mai stato un problema.

Altrimenti, penso che gli ORM siano per sviluppatori che non capiscono che meno è meglio, e penso che più fantastici strumenti di terze parti usano nella loro app, migliore sarà la loro app. Lascio cose come questa agli irriducibili uber geek mentre nel frattempo produco software molto più eccezionale che qualsiasi sviluppatore può apprendere ed essere immediatamente produttivo.

Le prestazioni di runtime sono l'unico vero svantaggio a cui riesco a pensare, ma penso che sia più di un giusto compromesso per il tempo che ORM ti fa risparmiare sviluppo / test / ecc. E nella maggior parte dei casi dovresti essere in grado di individuare i colli di bottiglia dei dati e modificare le strutture degli oggetti per essere più efficienti.

Non ho mai usato Hibernate prima, ma una cosa che ho notato con alcune soluzioni ORM "pronte all'uso" è la mancanza di flessibilità. Sono sicuro che questo dipende da cosa scegli e cosa devi farne.

Ci sono due aspetti degli ORM che sono preoccupanti. Innanzitutto, sono codice scritto da qualcun altro, a volte closed source, a volte open source ma di enorme portata. Secondo, copiano i dati.

Il primo problema causa due problemi. Ti affidi al codice di estranei. Lo facciamo tutti, ma la scelta di farlo non dovrebbe essere presa alla leggera. E se non fa quello che ti serve? Quando lo scoprirai? Vivi dentro la scatola che il tuo ORM disegna per te.

Il secondo problema è uno dei commit in due fasi. Il database relazionale viene copiato in un modello a oggetti. Si modifica il modello a oggetti e si suppone che aggiorni il database. Questo è un commit in due fasi e non è la cosa più facile da eseguire il debug.

Suggerisco questa lettura per un elenco degli aspetti negativi degli ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Per quanto mi riguarda, ho trovato gli ORM molto utili per la maggior parte delle applicazioni che ho scritto!

/ Asger

L'esperienza che ho avuto con Hibernate è che la sua semantica è sottile e quando ci sono problemi, è un po 'difficile capire cosa sta andando storto sotto il cofano. Ho sentito da un amico che spesso si inizia con Criteria, quindi ha bisogno di un po 'più di flessibilità e ha bisogno di HQL, e in seguito nota che dopo tutto è necessario SQL grezzo (ad esempio, Hibernate non ha l'unione AFAIK).

Inoltre, con ORM, le persone tendono facilmente a utilizzare in modo eccessivo le mappature / modelli esistenti, il che porta a un oggetto con molti attributi che non sono inizializzati. Quindi, dopo la query, all'interno della transazione Hibernate viene eseguito il recupero di dati aggiuntivi, che porta a un potenziale rallentamento. Inoltre, purtroppo, l'oggetto del modello di ibernazione a volte è trapelato nel livello dell'architettura della vista e quindi vediamo LazyInitializationExceptions.

Per usare ORM, uno dovrebbe davvero capirlo. Purtroppo si ha facilmente l'impressione che sia facile mentre non lo è.

Non per essere una risposta di per sé, voglio riformulare una citazione che ho sentito di recente. "Un buon ORM è come uno Yeti, tutti ne parlano ma nessuno lo vede."

Ogni volta che metto le mani su un ORM, di solito mi trovo alle prese con i problemi / i limiti di quell'ORM. Alla fine, sì, fa quello che voglio ed è stato scritto da qualche parte in quella schifosa documentazione, ma mi ritrovo a perdere un'altra ora che non avrò mai. Chiunque abbia usato nhibernate, quindi fluente nhibernate su postgresql capirebbe quello che ho passato. La sensazione costante di "questo codice non è sotto il mio controllo" fa davvero schifo.

Non punto il dito né dico che sono cattivi, ma ho iniziato a pensare a quello che sto regalando solo per automatizzare CRUD in una singola espressione. Oggigiorno penso che dovrei usare meno ORM, magari creare o trovare una soluzione che abiliti al minimo le operazioni db. Ma sono solo io. Credo che alcune cose siano sbagliate in questa arena ORM, ma non sono abbastanza abile per esprimere cosa no.

Penso che usare un ORM sia ancora una buona idea. Soprattutto considerando la situazione che dai. Dal tuo post sembra che tu sia il più esperto quando si tratta di strategie di accesso al db e vorrei far apparire usando un ORM.

Non ci sono argomenti per # 1 poiché copiare e incollare query e hardcoding nel testo non offre flessibilità, e per # 2 la maggior parte degli orm includerà l'eccezione originale, consentirà di tracciare le query generate, ecc., Quindi anche il debug non è scienza missilistica.

Per quanto riguarda la convalida, l'utilizzo di un ORM di solito consentirà anche di sviluppare più facilmente strategie di convalida, oltre a qualsiasi convalida incorporata.

Scrivere il proprio framework può essere laborioso e spesso le cose vengono perse.

EDIT: volevo sottolineare un altro punto. Se la tua azienda adotta una strategia ORM, ciò accresce ulteriormente il suo valore, poiché svilupperai linee guida e pratiche per l'utilizzo e l'implementazione e tutti miglioreranno ulteriormente la loro conoscenza del framework scelto, mitigando uno dei problemi che hai sollevato. Inoltre, imparerai cosa funziona e cosa no quando si verificano situazioni e alla fine risparmierai molto tempo e fatica.

Ogni ORM, anche "buono", viene fornito con un certo numero di presupposti correlati ai meccanismi sottostanti che il software utilizza per passare i dati avanti e indietro tra il livello dell'applicazione e l'archivio dati.

Ho scoperto che per applicazioni moderatamente sofisticate, lavorare intorno a questi presupposti di solito mi richiede più tempo rispetto alla semplice scrittura di una soluzione più diretta come: interrogare i dati e istanziare manualmente nuove entità.

In particolare, è probabile che si verifichino intoppi non appena si utilizzano chiavi a più colonne o altre relazioni moderatamente complesse che non rientrano nell'ambito dei pratici esempi forniti dal proprio ORM durante il download del codice.

Ammetto che per alcuni tipi di applicazioni, in particolare quelle che hanno un numero molto elevato di tabelle di database o tabelle di database generate dinamicamente, il processo di magia automatica di un ORM può essere utile.

Altrimenti, al diavolo gli ORM. Ora li considero fondamentalmente una moda passeggera.