Mapper O/R - Buono o cattivo

Question

Sono davvero distrutto in questo momento tra l'utilizzo di mapper O/R o semplicemente l'accesso ai dati tradizionali. Per qualche ragione, ogni volta che apro i mapper O/R, gli altri sviluppatori si lamentano e parlano di problemi di prestazioni o di come sono in generale cattivi. Cosa mi manca qui? Sto guardando LINQ a SQL e Microsoft Entity Framework. C'è qualche base per una di queste affermazioni? Che tipo di cose devo compromettere se voglio usare un mappatore O/R. Grazie.

Answer 1

Il problema che vedo con un sacco di mapper OR è che si ottengono oggetti di dominio gonfiati, che di solito sono altamente accoppiati con il resto del framework di accesso ai dati. Anche i nostri sviluppatori si lamentano di questo :) È solo più difficile trasferire questi oggetti su un'altra tecnologia di accesso ai dati. Se usi L2S, puoi dare un'occhiata al codice generato. Sembra un casino completo. NHibernate è probabilmente uno dei migliori in questo. Le tue entità sono completamente inconsapevoli del tuo livello di accesso ai dati, se le progetti correttamente.

Answer 2

Per prima cosa sono entrato nella mappatura ORM e nei livelli di accesso ai dati dalla lettura del libro di Rockford Lhotka, oggetti aziendali C#. Ha passato anni a lavorare su un framework per i DAL. Mentre il suo quadro fuori dagli schemi è abbastanza gonfio e in alcuni casi, eccessivo, ha alcune idee eccellenti. Consiglio vivamente il libro a tutti coloro che guardano i mapper ORM. Sono stato influenzato dal suo libro abbastanza da portare via molte delle sue idee e costruirle nel mio framework e nella mia generazione di codice.

Answer 3

All'inizio sembrerà una risposta non correlata, ma: uno dei miei interessi secondari sono gli aerei da combattimento dell'era della seconda guerra mondiale. Tutte le nazioni combattenti (Stati Uniti, Gran Bretagna, Germania, Unione Sovietica, Giappone ecc.) Costruirono un gruppo di combattenti diversi durante la guerra. Alcuni di essi utilizzavano motori radiali (P47, Corsair, FW-190, Zero); alcuni utilizzavano motori in linea raffreddati a liquido (Bf-109, Mustang, Yak-7, Spitfire); e alcuni hanno usato due motori invece di uno (P38, Do-335). Alcuni hanno usato mitragliatrici, alcuni hanno usato cannoni e altri ne hanno usati entrambi. Alcuni sono addirittura fatti di compensato, se puoi immaginarlo.

Alla fine, sono andati tutti molto velocemente, e nelle mani di un pilota esperto e competente, avrebbero sparato al culo del debuttante in un batter d'occhio. Non immagino che molti piloti volassero in giro pensando "oh, quell'idiota sta volando con un motore radiale - non devo preoccuparmi affatto di lui". Tutti hanno capito che c'erano molti modi diversi per raggiungere l'obiettivo finale, e ogni approccio aveva i suoi particolari vantaggi e svantaggi, a seconda delle circostanze.

Il dibattito tra ORM e accesso ai dati tradizionali è proprio come questo, ed è necessario che ogni programmatore diventi competente con entrambi gli approcci e scelga l'opzione giusta per il lavoro da svolgere.

Answer 4

Ho lottato con questa decisione per molto tempo. Penso di essere titubante per due motivi principali. In primo luogo, i mappatori O/R rappresentavano una mancanza di controllo su ciò che stava accadendo in una parte critica dell'app e, in secondo luogo, perché così tante volte sono stato deluso da soluzioni che sono eccezionali per il 90% del caso ma miserabili per l'ultimo 10%. Naturalmente, tutto funziona per select * dagli autori, ma quando aumenti la complessità e hai un sistema critico ad alto volume e la tua carriera è in linea, senti che devi avere il controllo completo per sintonizzare ogni modello di query e byte sopra il filo. La maggior parte degli sviluppatori, incluso me, si sentono frustrati la prima volta che lo strumento non ci riesce, e non possiamo fare ciò che dobbiamo fare, o il nostro bisogno devia dal modello stabilito supportato dallo strumento. Probabilmente sarò fiammeggiato per aver menzionato difetti specifici negli strumenti, quindi lo lascerò.

Fortunatamente, Anderson Imes alla fine mi ha convinto a provare CodeSmith con il netTiers template. (No, non lavoro per loro.) Dopo più di un anno di utilizzo di questo, non posso credere di non averlo fatto prima. Il mio team utilizza Visual Studio DB Pro e ad ogni check-in la nostra build di integrazione continua elimina una nuova serie di assembly del livello di accesso ai dati.Questo gestisce tutte le cose comuni, a basso rischio automaticamente, ma possiamo ancora scrivere sprocs personalizzati per i bit più complessi e averli inclusi come metodi sulle classi generate, e possiamo anche personalizzare i modelli per il codice generato. Consiglio vivamente questo approccio. Potrebbero esserci anche altri strumenti che consentono questo livello di controllo, e c'è un nuovo modello CodeSmith chiamato PLINQO che usa LINQ to SQL sotto il cofano. Non abbiamo ancora esaminato (non ne abbiamo avuto bisogno), ma questo approccio generale ha molto valore.

Jerry

Answer 5

Non c'è una risposta semplice a questo dal momento che ogni fornitore di ORM avrà è di possedere particolari vantaggi e svantaggi. Alcune soluzioni ORM sono più flessibili di altre. L'onere dello sviluppatore è di comprenderli prima di usarne uno.

Tuttavia, prendi LinqToSql - se sei sicuro di non dover passare da SQL Server, questo risolve molti dei problemi più comuni riscontrati nei mapper ORM. Ti permette di aggiungere facilmente stored procedure (come metodi statici), quindi non sei solo limitato a SQL generato. Utilizza l'esecuzione posticipata, in modo da poter raggruppare le query in modo efficiente. Usa le classi parziali per consentire di aggiungere facilmente la logica personalizzata alle classi generate senza doversi preoccupare di cosa succede quando le ri-generate. Inoltre, non c'è nulla che ti impedisca di usare LINQ per creare il tuo DAL astratto, ma accelera il processo. La cosa principale, tuttavia, è che allevia la noia e il tempo necessario per creare uno strato CRUD di base.

Ma ci sono anche aspetti negativi. Ci sarà un accoppiamento stretto tra i tuoi tavoli e le tue classi, ci sarà un leggero calo delle prestazioni, potresti occasionalmente generare query che non sono efficienti come previsto. E sei legato a SQL Server (anche se alcuni altri tecnlogie ORM sono indipendenti dal database).

Come ho detto, l'importante è essere consapevoli dei pro e dei contro prima di fissare i colori a una particolare metodologia.

Answer 6

Strumenti O/RM progettati per funzionare molto bene nella maggior parte delle situazioni. Memorizzerà le entità per te, eseguirà query in gruppi, ha un accesso ottimizzato a oggetti di livello molto basso che è molto più veloce dell'assegnazione manuale dei valori alle proprietà, ti offre un modo molto semplice per incorporare le variazioni della programmazione orientata all'aspetto usando tecniche moderne come gli intercettori, gestirà lo stato delle entità per te e aiuterà a risolvere i conflitti e molti altri.

Gli svantaggi di questo approccio sono in genere la mancanza di comprensione di come le cose funzionano a un livello molto basso. Il problema più classico è "SELEZIONA N + 1" (link).

ho lavorato con NHibernate per 2,5 anni, e sto ancora scoprire qualcosa di nuovo su di esso quasi ogni giorno ...

Answer 7

Good. Nella maggior parte dei casi.

Il vantaggio di produttività dell'utilizzo di un ORM, nella maggior parte dei casi supererà la perdita di controllo su come i dati sono accessibili.

Non ci sono molti che eviterebbero C#, al fine di programmare è MSIL o Assembly, anche se ciò darebbe loro un maggiore controllo.

Answer 8

Dipende davvero dalla situazione.

Sono passato da un'azienda che ha utilizzato un ORM ottimizzato per un'azienda che non ha utilizzato un ORM e ha scritto query SQL tutto il tempo.Quando ho chiesto di usare un ORM per semplificare il codice, ho ottenuto quello sguardo vuoto di fronte seguito da tutti gli aspetti negativi di essa:

• sua alta Bloat
• non si dispone di un controllo preciso le vostre domande ed eseguire quelle inutili
• v'è un oggetto pesante per la mappatura tavolo
• il suo codice non secca perché si deve ripetere la vostra auto

su un on

Ebbene, dopo aver lavorato lì per un paio di settimane, avevo notato che:

• abbiamo avuto diverse query che erano quasi identici, e un sacco di volte se c'era un bug, solo una manciata otterrebbe fisso
• invece di memorizzare nella cache le query di tabelle comuni, avremmo finito di leggere una tabella più volte.
• Stavamo ripetendo noi stessi dappertutto
• Abbiamo avuto diversi livelli di livello di abilità, quindi alcune query non sono state scritte nel modo più efficiente.

Dopo aver indicato la maggior parte di questo, hanno scritto un "DBO" perché non volevano chiamarlo un ORM. Hanno deciso di scriverne uno da zero invece di modificarne uno.

Inoltre, molte delle argomentazioni derivano dall'ignoranza contro i sentimenti di ORM. Ogni ORM che ho visto consente query personalizzate e, anche seguendo le convenzioni dell'ORM, è possibile scrivere query molto complesse e dettagliate e normalmente sono più leggibili. Inoltre, tendono ad essere molto ASCIUTTI, a dare loro il tuo schema, e calcolano il resto, fino alla mappatura delle relazioni.

Gli ORM moderni dispongono di numerosi strumenti per aiutarti, come gli script di migrazione, più tipi di DB a cui è possibile accedere agli stessi oggetti, in modo da sfruttare i vantaggi sia dei NOSQL che dei DB SQL. Ma devi scegliere l'ORM giusto per il tuo progetto se ne userai uno.