Domanda

Mi vergogno di dirlo, ma devo farlo. Non ho lavorato con ORM. Sto davvero prendendo in considerazione NHibernate in quanto sembra essere il prodotto più maturo per .Net là fuori (per favore correggimi se sbaglio). Ora, il fatto è che abbiamo un grande sistema di e-commerce / prenotazione con un SqlServer come principale punto di integrazione, che contiene un sacco di logica di business negli sprocs. Ora - ovviamente - questa architettura è qualcosa da cui vogliamo allontanarci e lo facciamo da tempo, pezzo per pezzo. Quindi, la mia vera domanda è quanto sia possibile iniziare a utilizzare NHibernate per nuove funzionalità e non tornare indietro e mappare tutte le cose legacy? Questo tipo di introduzione graduale di e ORM è supportato e, in tal caso, lo consiglieresti?

È stato utile?

Soluzione

Dipenderà da come " NHibernate friendly " il tuo database attuale è. A NHibernate piacciono le chiavi primarie a colonna singola (se sono tutte denominate & Quot; id & Quot; ancora meglio). La maggior parte degli ORM non sono molto adatti ai processi, per quanto ne so. Hai pensato a come definirai i tuoi oggetti di trasferimento per ottenere i dati avanti e indietro dal db?

A proposito non c'è nulla di cui vergognarsi. Gli ORM sono una cosa da capogiro ma hai ragione nel cercare di trovare l'approccio migliore.

Altri suggerimenti

Se stai utilizzando database legacy, troverai strumenti ORM piuttosto difficili da usare, configurare, mantenere e ottimizzare. Ci siamo imbattuti in molti problemi quando abbiamo usato NHibernate per mappare il nostro modello di dominio a un database esistente. Alcuni di loro erano:

  1. Gli oggetti Model erano difficili da mappare su tabelle esistenti (avevamo oltre 100 tabelle), alcuni dei requisiti di NHibernate erano piuttosto invadenti come ogni tabella deve avere un campo ID per poter essere mappata in un oggetto Dominio . Inoltre, mappare molte o molte relazioni era piuttosto difficile da comprendere e usare.

  2. Mantenimento del grande volume di mappatura dell'XML richiesto per il mapping il database legacy è diventato a tempo pieno lavoro per uno sviluppatore ed era abbastanza impegnativo, specialmente in una squadra di 10+ sviluppatori.

  3. Le nostre query sono peggiorate in termini di prestazioni con l'aumentare della complessità poiché il modello di dati e il modello di oggetti non sempre corrispondevano all'affare e dovevano essere costantemente sintonizzati. È stata scritta una grande quantità di codice di aggregazione dei dati. Ad esempio, se avessimo bisogno di mostrare una griglia che univa più tabelle, dovevamo caricare più oggetti Dominio per metterli insieme e mostrarli in una griglia. Quel codice era difficile da mantenere ed eseguire il debug.

  4. Inoltre, a volte dovevamo eseguire query anonime, ovvero dove volevamo solo alcune proprietà da alcuni oggetti e non dagli oggetti interi. Era davvero difficile scrivere, mantenere e persino implementare e andava contro il paradigma ORM, ma non avevamo altra scelta che farlo.

  5. Un altro problema che abbiamo riscontrato è stato il costante mutamento del Database in quanto i DBA avrebbero riformattato le tabelle e avrebbero sempre rotto i nostri oggetti Dominio. È stato un esercizio mantenere sincronizzati i modelli e le tabelle e anche assicurarsi che l'app funzionasse ancora.

Per farla breve ... Quello che abbiamo appreso che se esistesse un modo per mappare l'SQL di cui l'azienda aveva bisogno direttamente sul nostro modello UI o sugli oggetti Dominio senza doversi preoccupare della configurazione, sarebbe una soluzione migliore.

Dopo aver vissuto questa esperienza, abbiamo sviluppato Orasis Mapping Studio. È uno strumento di mappatura appositamente progettato per funzionare con database legacy e anche oggetti .NET Model / Domain esistenti. Accetta le tue query SQL e ti consente di mapparle sui tuoi oggetti .NET esistenti mostrando graficamente i metadati della Query e dell'Oggetto e usando il drag and drop per creare mappature tra le proprietà dell'Oggetto e le colonne della Query. Lo strumento genera automaticamente tutto il codice ADO.NET necessario per eseguire il mapping per leggere i tuoi oggetti. È quindi possibile utilizzare il codice generato nel proprio livello DAL o utilizzare l'Assemblea generata per recuperare e conservare i dati.

Puoi provarlo qui: Orasis Mapping Studio . È uno strumento di cui crediamo davvero che gli sviluppatori abbiano bisogno, specialmente per lavorare con database legacy e dove le prestazioni sono un requisito chiave. È stato scritto da sviluppatori per sviluppatori, quindi gestisce alcuni dei dettagli complessi come l'eredità di Obejct, gli oggetti nidificati, le conversioni dei tipi di dati, ecc. Buona fortuna!

Non l'ho fatto personalmente, ma è possibile copiare e incollare le procedure memorizzate nelle query denominate nei file di mappatura e rimuoverle una dopo l'altra.

Se non hai alcuna esperienza con gli ORM, probabilmente potrebbe essere difficile iniziare ad impararlo in un grande progetto legacy, perché devi scoprire tutte le funzionalità non standard dell'ORM che non utilizzeresti nei progetti greenfield o utilizzare solo una volta all'anno. NHibernate ha molte opzioni per supportare database legacy.

Quando sei pronto per attraversare la curva di apprendimento e coraggioso abbastanza da iniziare a utilizzare una nuova tecnologia, puoi iniziare con NHibernate, ma se ti piace imparare nuove tecnologie passo dopo passo, aspetterei con NHibernate finché non inizi una nuova progetto greenfield.

Qualsiasi strumento ORM decente dovrebbe supportare l'integrazione graduale. Il trucco qui è quello di avere una chiara separazione a livello di DAO (livello di accesso ai dati). Se riesci a nascondere le tue stranezze di accesso ai dati tramite un'API ben definita, non dovrebbe importare se stai utilizzando un ORM o meno.

Detto questo, la complessità dell'introduzione ORM è direttamente correlata alla complessità dei modelli di tabella. Puoi avere molti mapping diversi per le stesse tabelle, assicurati solo di fare alcune prove in anticipo per conoscere le stranezze di una soluzione ORM come avere una cache degli oggetti, query write-behind, accesso proxy e così via. Il vero vantaggio di una soluzione ORM è l'utilizzo di oggetti anziché di classi POJO fittizie. Ciò rende molto più semplice apportare modifiche al business rispetto all'utilizzo di sprocs o oggetti piatti.

Come nota a margine, ho lavorato su un progetto in cui abbiamo migrato un'intera app in sprocs su java. Sebbene non abbiamo usato uno sproc, il vero dolore era che l'architettura degli sprocs non era ben definita, molti sprocs che chiamavano altri sprocs rendevano molto difficile migrare solo alcuni sprocs alla volta.

All'interno di NHibernate non c'è nulla che ti impedisca di farlo. Ad un certo punto probabilmente vorrai convertire il tuo codice legacy per utilizzare anche NHibernate in quanto non vedrai tutti i vantaggi di un ORM fino a quando non potrai navigare tra le relazioni tra tutti i tuoi oggetti.

La più grande sfida con questo potrebbe essere quella di far sì che le strutture della tabella legacy si adattino alla metodologia della singola tabella di NHibernate per classe. Ci sono modi per aggirare questo, ma può essere difficile. Tuttavia, penso che valga la pena.

Hai menzionato che ti stai allontanando dalla tua architettura attuale, ma sei tenuto a rispettare la progettazione del database legacy (ad esempio un DBA è strettamente responsabile per la progettazione e la manutenzione) o il tuo progetto di database corrente viene refactored (con considerazione anche per un mapper O / R)?

Se è difficile allontanarsi dal tuo attuale progetto legacy, probabilmente potresti considerare di esaminare qualcos'altro come iBATIS SqlMap a O / R associa entità al database legacy utilizzando semplici query T-SQL piuttosto che semplici attributi / XML non flessibili in stile Hibernate per mappare i dati.

A seconda di come vuoi avvicinarti al design, puoi usare iBATIS SqlMap e NHibernate in modo trasparente fianco a fianco, sfruttando il tuo abstract DAO factory o iBATIS DataAccess API (che essenzialmente lo fa, ed è ancora compatibile con NHibernate.)

Sono d'accordo con quello che ha detto Ahmad, ho affrontato problemi simili in passato. La maggior parte dei problemi che avevo non derivava dalla tecnologia stessa, ma dalla sua adozione da parte degli sviluppatori, il passaggio a NHibernate implica cambiamenti nelle abitudini di lavoro, per non dire altro, e questo non è sempre facile.

Se non conosci ORM, è probabilmente meglio iniziare un nuovo progetto piuttosto che provare a convertire un progetto precedente.

Il mio consiglio per convertire un progetto legacy in ORM sarebbe quello di provare a usare una sorta di strumento di generazione come LLBGen o .netTiers o persino Linq2SQL. In questo modo potresti sentirti un po 'più a tuo agio con ORM senza la riscrittura traumatica che NHibernate potrebbe imporre.

Perché i processi memorizzati " ovviamente " male? La logica aziendale nei processi archiviati sta causando dolore?

Microsoft sembra avere a disposizione diverse tecnologie di persistenza (ad es. LINQ). Non so come valutarli rispetto a NHibernate, ma non consiglierei ORM a meno che tu non abbia oggetti davvero buoni su cui mappare.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top