Che cosa c'è di così bello nell'ORM?

Quindi sto avendo una testa contro il muro e sperando che qualcuno possa venire ad aiutare a rimuovere il muro o a fermare la mia testa dal muoversi !!Che cosa c'è di così bello nell'ORM?

Nelle ultime 3/4 settimane ho indagato su ORM in preparazione per un nuovo progetto. L'ORM deve essere associato a un database SQL esistente, grande e obsoleto.

Così ho provato Subsonic. Mi è piaciuto molto v2 e v3 dopo che modding funzionava bene con VB e gli schemi con nome in SQL funzionavano correttamente. Tuttavia, la sua mancanza di flessibilità di avere i nomi delle proprietà delle entità separate rispetto ai nomi delle colonne mi ha fatto tirare fuori i capelli (mi dispiace Rob).

Ho provato Entity Framework ma ho trovato come altri mancano in alcune aree.

Così ho morso il proiettile e ho provato nHibernate ma dopo una settimana circa ho funzionato come mi piaceva (con l'aiuto di Codesmith per generare classi/hbms per me) sono frustrato dal tempo necessario all'avvio (build un oggetto config), nonostante provi un certo numero di trucchi per ridurre questo tempo.

Sono essenzialmente dopo aver creato una classe DAL che posso condividere tra app e siti web. Sto abbaiando dall'albero sbagliato? Per un progetto legacy con 100 di tabelle dovrei tornare ad ado.net e usare DTO? Aarrgh!

Ci scusiamo per lo stile di domanda esiguo. Non mi restano molti capelli e vorrei conservare quello che ho !!

Grazie in anticipo, Ed

PS. Devo aggiungere che conosco SQL molto bene e non ho paura di sporcarmi le mani per scrivere query veloci. Se qualcosa non ho bisogno di essere nascosto da SQL

fonte

2010-02-09 CResults

Che tipo di applicazione si fa a avere in modo che il tempo di avvio NHibernate è un problema? IMO, dovrebbe infastidirti solo se accedi direttamente al DB dal desktop, non nel caso di un servizio di livello intermedio. –

@Dmitry: hai ragione +1 –

Potresti semplificare questo rant piuttosto semplicemente chiedendo "Come posso velocizzare il tempo di avvio di un'applicazione di NHibernate?". –

ORM vi let:

Per mappare le righe della tabella a oggetti, che sono i pezzi lavorabili di programmazione orientata agli oggetti.
Per spostarsi automaticamente attraverso relazioni oggettuali
Per aggiungere, modificare e rimuovere le righe della tabella
Per interrogare il database in modo più intuitivo come non si deve pensare di join (questo dipenderà dalla ORM e il metodo di query)
Per gestire in modo trasparente la cache L1 e L2.

Tutte le operazioni precedenti devono essere gestite manualmente se non si utilizza ORM.

PS: Accetto Dmitry per quanto riguarda il tempo di avvio di NHibernate (vedere commenti alle domande). Inoltre, hai provato Fluent NHibernate? Fluente NHibernate è straordinariamente facile. Non potevo credere ai miei occhi quando ho mappato per la prima volta un database. È ancora più semplice rispetto agli ORM proprietari come DevExpress XPO.

fonte

2010-02-09 11:01:12

+1 per la raccomandazione di FluentNHibernate. Attualmente lo sta usando su un progetto ed è davvero "straordinariamente facile". –

Nella mia esperienza, la maggior parte degli ORM finiscono per essere molto più complessa di SQL. Che sconfigge l'intero scopo di usarli.

Una soluzione di cui sono entusiasta è LINQ2SQL. Eccelle come un sottile strato su stored procedure o viste. È davvero facile da usare e non tenta di nascondere SQL.

fonte

2010-02-09 11:00:29 Andomar

Posso simpatizzare con la questione della complessità; la maggior parte degli strumenti ORM è diabolicamente complessa da configurare. Direi che risolvono una gamma di problemi significativamente complessa per giustificare la loro complessità, e che il valore ottenuto nel loro utilizzo è superiore alla pena di imparare come usarli. –

Andomar: Gli ORM, in generale, espongono oggetti, non SQL. Questo è il punto. Perché stai usando un ORM se non mappare le tabelle relazionali sugli oggetti? Forse ADO.NET è più adatto alle tue esigenze. –

Andomar: Hai guardato @ PLINQO? Ho mappato lo stesso database con esso e Codesmith e ho finito con meno errori e tempi di esecuzione molto più veloci - nessun ritardo di avvio fuori dalla scatola. – CResults

Il più grande vantaggio di uno strumento ORM è che ti aiuterà a stratificare correttamente l'applicazione. La maggior parte dei progetti al giorno d'oggi usa un Data Layer per connettersi al database.Si inizia dallo strumento ORM per produrre classi che corrispondono agli oggetti del database. Quindi definisci un'interfaccia usando questi metodi. Tutto il codice di persistenza utilizza i metodi di questa interfaccia. In questo modo il livello della logica di business è solo accoppiato a questa interfaccia di livello superiore e non ha bisogno di sapere nulla sul database. In realtà non dovrebbe esserci alcuna dipendenza da ADO.NET o persino da NHibernate.

Un altro vantaggio degli strumenti ORM è il disaccoppiamento dell'applicazione dal server del database. È possibile modificare il motore di database e utilizzare ancora lo stesso codice. Inoltre non c'è solo la complessità dell'SQL che l'ORM ti nasconde. Può anche aiutare con la logica delle transazioni e il pool di connessioni.

Direi che per i nuovi progetti uno strumento ORM è una necessità. Per i progetti legacy non è molto vantaggioso, a meno che, naturalmente, non si disponga di tempo/denaro per iniziare da zero.

fonte

2010-02-09 11:13:06 kgiannakakis

+1 per enfatizzare il disaccoppiamento. Questo è il motivo per cui sostengo con forza gli strumenti ORM e l'utilizzo del modello di repository. –

Gli strumenti ORM non aiutano con il disaccoppiamento. La logica di presentazione può ancora utilizzare ADO.NET o SQL tramite i meccanismi ORM per comunicare con il database. LinqToSql vuole essere il tuo livello aziendale e in effetti rende complicato separare la logica di business e dati. Nella maggior parte dei casi, gli ORM non possono nascondere alcun codice SQL diverso dal CRUD di base e cercare per nome/id tipo di query. Gli ORM possono essere utili per i progetti precedenti e non sempre hanno senso per i nuovi progetti. –

Gli strumenti ORM * do * aiutano con il disaccoppiamento. Come ho scritto, questa non è l'unica cosa che devi fare, dato che devi ancora definire i metodi dell'interfaccia, che nasconderanno le dipendenze dalle librerie ORM. Questi metodi possono utilizzare tuttavia classi come "Cliente" o "Ordine" create con lo strumento ORM e mappate al database. – kgiannakakis

Ci sono fondamentalmente due domande qui:

Cosa c'è di bello negli ORM? Ci sono domande simili su Stackoverflow. Vedi:

Come posso migliorare NHibernate tempo di avvio? Vedere:

fonte

2010-02-09 11:19:13

Che cosa c'è di così bello nell'ORM?

risposta

Problemi correlati