Quando si sceglie un ORM, LINQ to SQL o LINQ to Entities è migliore di NHibernate?

Question

Trovo di poter fare di più con NHibernate e persino Castle che con Linq to Entities o linq to SQL.

Sono pazzo?

Answer 1

No, non sei pazzo.nHibernate è un mappatore OR completo, Linq to SQL e Linq to Entities non implementano tutto ciò che ti aspetteresti da un mappatore OR e sono destinati a un gruppo di sviluppatori leggermente diverso.

Ma non lasciarti scoraggiare da Linq.Linq è ancora una buona idea..Prova Linq to nHibernate :-)

Answer 2

Il grande svantaggio di NHibernate, Castle, ecc. è che non sono esattamente leggeri (specialmente NHibernate).

Linq to SQL è utile per un ORM leggero e ad uso limitato.

Answer 3

Ho utilizzato sia NHibernate che LINQ to SQL.Dal mio punto di vista dipende dal progetto, se ho bisogno di qualcosa di veloce sceglierei L2S, è semplicissimo creare la mappatura dbml e iniziare ad usarlo.Se sto sviluppando una soluzione aziendale di livello più elevato, opterei per il collaudato e affidabile ORM - NHibernate, trovo che le funzionalità di registrazione e transazione siano semplici da usare.

LINQ to SQL ha una curva di apprendimento relativamente breve, NHibernate ha una curva di apprendimento molto più ripida.

LINQ to SQL supporta solo SQL Server, quindi se disponi di un database Oracle la decisione è già presa: NHibernate.

Consiglierei di dare un'occhiata http://www.summerofnhibernate.com/ per eccellenti screencast sull'apprendimento di NHibernate.

Answer 4

Una cosa da tenere a mente è che NHibernate può essere un vero e proprio maiale da configurare, soprattutto perché si basa principalmente su file di configurazione XML a causa delle sue radici come Hibernate originale.

Hibernate fluente contribuisce in qualche modo a rendere tutto questo meno doloroso.

Linq certamente si adatta al "modo" generale in cui funziona .NET.

Answer 5

Blockquote Linq certamente si adatta al "modo" generale in cui funziona .NET

Cavolo, questo tipo di sentimento mi spaventa.Il materiale RAD integrato in .net NON è il modo in cui funziona dot net, è solo un set di strumenti per creare prototipi..NET ci consente di realizzare applicazioni DDD complete, con alti livelli di coesione, separazione delle preoccupazioni e ci consente di scrivere codice disaccoppiato, nonostante tutti i tentativi che ms fa per accoppiare le cose.Non sono assolutamente d'accordo sul fatto che a .net piaccia essere accoppiato, agli strumenti certiani piace essere accoppiati, includerò linq to sql in questa mischia.linq to sql distrugge l'idea di avere un modello di dominio separato.Rabbrividisco al pensiero di utilizzare lo schema del mio database come oggetti del modello sottostante.Strumenti ORM adeguati dovrebbero consentirci di modellare prima il nostro dominio, quindi collegare il nostro database relazionale a questi modelli.Non il contrario.

Answer 6

Non ho provato Entity Framework, ma consiglierei sicuramente NHibernate su Linq to SQL;Il motivo principale che posso fornire è solo il controllo.A Linq to SQL piace avere molto più controllo su tutto, caricando l'oggetto e mantenendo tutti i tipi di informazioni di tracciamento sull'oggetto.Se si serializza/deserializza, le informazioni di tracciamento possono andare perse e possono accadere cose strane quando le si salva nuovamente.NHibernate funziona più come dovrebbe fare un repository: gli dai qualunque oggetto tu voglia (che lo hai configurato per capirlo, ovviamente), e lo mette nel database, indipendentemente da cosa ne hai fatto.