NHibernate vs LINQ to SQL

StackOverflow https://stackoverflow.com/questions/26971

Domanda

Come qualcuno che non ha usato la tecnologia in progetti veri e propri, mi chiedo se qualcuno sa come questi due si completano a vicenda e quanto la loro funzionalità si sovrappongono?

È stato utile?

Soluzione

LINQ to SQL ti costringe a usare la tavola-per-classe modello.I vantaggi dell'utilizzo di questo modello sono che è veloce e facile da implementare e richiede poco sforzo per ottenere il vostro dominio in esecuzione basato su una struttura del database esistente.Per le applicazioni più semplici, questo è perfettamente accettabile (e spesso anche preferibile), ma per le applicazioni più complesse, gli sviluppatori spesso suggeriscono di usare un domain driven design motivo invece (che è quello che NHibernate facilita).

Il problema con il tavolo-per-classe modello è che la struttura del database ha un'influenza diretta sul tuo dominio design.Per esempio, supponiamo di avere una tabella Clienti con le seguenti colonne di tenere un cliente primaria indirizzo:

  • StreetAddress
  • Città
  • Stato
  • Zip

Ora, supponiamo che si desidera aggiungere colonne per il cliente, l'indirizzo postale e quindi aggiungere le seguenti colonne per la tabella Clienti:

  • MailingStreetAddress
  • MailingCity
  • MailingState
  • MailingZip

Utilizzando LINQ to SQL, il Cliente oggetto nel dominio avrebbe proprietà per ciascuno di questi otto colonne.Ma se hai seguito un domain driven design pattern, si sarebbe probabilmente hanno creato un Indirizzo di classe e aveva il vostro Cliente di classe tenere due proprietà di Indirizzo, uno per l'indirizzo postale e uno per la loro attuale indirizzo.

Questo è un semplice esempio, ma dimostra come il tavolo-per-classe modello può portare a un po ' puzzolente di dominio.Alla fine, tocca a voi.Di nuovo, per applicazioni semplici che hanno bisogno di base CRUD (create, read, update, delete) funzionalità, LINQ to SQL è l'ideale per la semplicità.Ma personalmente mi piace usare NHibernate, perché facilita un pulitore di dominio.

Edit:@lomaxx - Sì, l'esempio che ho utilizzato è semplice e potrebbe essere stato ottimizzato per funzionare bene con LINQ to SQL.Volevo tenerlo come base, come possibile guidare a casa il punto.Il punto rimane però che ci sono diversi scenari in cui avendo la struttura del database determinare la struttura di dominio sarebbe una cattiva idea, o almeno portare a non ottimale OO design.

Altri suggerimenti

Due punti persi finora:

  • LINQ to SQL non funziona con Oracle o qualsiasi database di oltre SqlServer. Tuttavia 3 parti di offrire un migliore supporto per Oracle, ad esempio devArt del dotConnect, DbLinq, Mindscape del LightSpeed e ALinq.(Non ho alcuna esperienza personale con questi)

  • Linq to NHibernate consente di usato Linq con un Nhiberate, quindi potrebbe rimuovere una ragione per non utilizzare.

Anche il nuovo interfaccia fluida, di Nhibernate sembra rendere meno doloroso per configurare Nhibernate di mapping.(La rimozione di uno dei punti deboli di Nhibernate)

Aggiornamento

Linq to Nhiberate è meglio in Nhiberate v3 che è ora in alfa.Sembra Nhiberate v3 possono nave verso la fine di quest'anno.

Il Entity Frame Work come di .rete 4 è anche cominciando a guardare come una vera opzione.

@Kevin:Penso che il problema con l'esempio che si sta presentando è che si sta utilizzando un povero progettazione di database.Avrei pensato di creare una tabella clienti e una tabella di indirizzi e normalizzato i tavoli.Se è quello, si può sicuramente usare Linq To SQL per lo scenario che si sta proponendo.Scott Guthrie ha un grande serie di post sull'utilizzo di Linq To SQL che mi consiglia vivamente il check-out.

Non credo che si potrebbe dire di Linq e NHibernate si completano a vicenda come che implica che essi possano essere utilizzati insieme, e mentre questo è possibile, è molto meglio scegliere uno e attenersi ad esso.

NHibernate consente di mappare le tabelle del database a oggetti del dominio estremamente flessibile.Esso permette anche di utilizzare HBL per interrogare il database.

Linq to SQL, inoltre, consente di mappare gli oggetti di dominio per il database, tuttavia, non utilizzare Linq sintassi di query per interrogare il database

La differenza principale è che le query Linq sintassi è selezionata al momento della compilazione il compilatore per garantire che le vostre domande sono validi.

Alcune cose di essere a conoscenza di linq è che è disponibile solo nel .rete 3.x ed è supportato solo in VS2008.NHibernate è disponibile nella versione 2.0 e 3.x così come VS2005.

Alcune cose di essere a conoscenza di NHibernate, è quello di non generare oggetti del dominio, e non genera il file di mapping.È necessario eseguire questa operazione manualmente.Linq può
farlo automaticamente per voi.

NHibernate Fluent in grado di generare i file di mapping basato su semplici convenzioni.XML-scrittura e fortemente tipizzato.

Recentemente ho lavorato su un progetto in cui abbiamo bisogno di cambiare da Linq to SQL Per NHibernate per motivi di prestazioni.In particolare L2S modo di materializzare gli oggetti sembra più lento del NHibernate idem e la gestione del cambiamento è piuttosto lento, troppo.E può essere difficile da girare la gestione del cambiamento off per specifici scenari in cui non è necessario.

Se avete intenzione di usare il vostro entità disconnesso da DataContext - in WCF scenari per esempio - sei può avere un sacco di problemi di connessione li a DataContext di nuovo per aggiornare le modifiche apportate.Non ho avuto nessun problema con che con NHibernate.

La cosa che mi mancherà da L2S è soprattutto la generazione di codice che tiene i rapporti up-to-date su entrambe le estremità delle entità.Ma credo che ci sono alcuni strumenti per NHibernate per fare quello che c'è fuori troppo...

Puoi chiarire cosa intendi per "LINQ"?

LINQ non è una tecnologia di accesso ai dati, è solo una caratteristica del linguaggio che supporta l'esecuzione di query come un nativo di costruire.È possibile eseguire una query su qualsiasi modello di oggetto che supporta interfacce specifiche (ad es.IQueryable).

Molte persone si riferiscono a LINQ To SQL come LINQ, ma non è affatto corretto.Microsoft ha appena rilasciato LINQ To Entities con .NET 3.5 SP1.Inoltre, NHibernate è un LINQ interfaccia, è possibile utilizzare LINQ e NHibernate per ottenere i vostri dati.

Da LINQ, sto supponendo che si intende LINQ to SQL, LINQ, di per sé, non ha il database di "andirivieni" associati con esso.È solo un linguaggio di query che ha un battello carico di syntac zucchero per farlo sembrare SQL-ish.

Nella base di esempi di base, NHibernate e LINQ to SQL sembrano essere entrambi risolvere lo stesso problema.Una volta a ottenere il pass che ben presto si accorgeranno che NHibernate ha il supporto per un sacco di funzionalità che consentono di creare davvero ricca di modelli di dominio.C'è anche un LINQ per NHibernate progetto che consente di utilizzare LINQ to query NHibernate in modo molto simile a come utilizzare LINQ to SQL.

In primo luogo permette di separare due cose diverse:Modellazione di Database è preoccupato per i dati, mentre per la modellazione di oggetti è preoccupato di entità e relazioni.

Linq-to-SQL vantaggio è quello di generare rapidamente le classi di fuori dello schema del database, in modo che possano essere utilizzati come attivo oggetti di record (vedi record attivo di un modello di progettazione di definizione).

NHibernate vantaggio è quello di consentire la flessibilità tra l'oggetto e modellazione modellazione di database.Il Database può essere modellato per riflettere al meglio i tuoi dati prendendo in considerazione le prestazioni, per esempio.Mentre il vostro oggetto di modellazione meglio riflettere gli elementi della regola di business, utilizzando un approccio come il Domain-Driven Design.(vedi Kevin Pang commento)

Con database legacy con scarsa modellazione e/o convenzioni di denominazione per poi Linq-to-SQL terrà conto di questo, indesiderate e nomi per le classi.Tuttavia NHibernate può nascondere questo pasticcio con i dati mappatori.

In greenfield progetti in cui database sono buone denominazione e bassa complessità, Linq-to-SQL può essere una buona scelta.

Tuttavia, è possibile utilizzare Fluente NHibernate con auto-mapping per questo stesso scopo con la mappatura come convenzione.In questo caso non preoccuparsi di eventuali dati mappatori con XML o C# e lasciare che NHibernate per generare lo schema del database da entità basata su una convenzione che è possibile personalizzare.

D'altra parte, la curva di apprendimento di Linq-to-SQL è più piccolo di NHibernate.

Oppure si potrebbe usare il Castello ActiveRecords progetto.Ho usato per un breve periodo di tempo di rampa di salita nuovo codice per un progetto di eredità.Utilizza NHibernate e funziona sul modello di record attivo (sorprendente dato il suo nome, lo so).Non ho provato, ma presumo che una volta che hai usato, se si sente il bisogno di cadere per NHibernate direttamente il supporto, non sarebbe troppo da fare così per tutti o per parte del progetto.

Come è scritto "per una persona che non sia di loro" LINQ to SQL è facile da usare, così uno può usare facilmente Inoltre, le procedure di supporto, che aiuta la maggior parte del tempo.Si supponga che si desidera ottenere i dati da più di una tabella, quindi scrivere una procedura e trascinare la procedura di progettazione e darà tutto per voi, Supponiamo che la vostra procedura di nome "CUSTOMER_ORDER_LINEITEM" che recuperare record da questi tre di tabella quindi basta scrivere

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

è possibile utilizzare i record di oggetto nel ciclo foreach, che non è supportato da NHibernate

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