NHibernate vs LINQ to SQL

Question

Comme quelqu'un qui n'a pas utilisé la technologie sur des projets réels, je me demande si quelqu'un sait comment ces deux complètent les uns les autres et la façon dont beaucoup de leurs fonctionnalités se chevauchent?

Answer 1

LINQ to SQL vous oblige à utiliser la table par classe de modèle. Les avantages de l'utilisation de ce modèle sont qu'il est facile et rapide à mettre en oeuvre et il prend très peu d'efforts pour obtenir votre domaine en cours d'exécution basé sur une base de données existante structure. Pour les applications simples, ce qui est parfaitement acceptable (et souvent même préférable), mais pour des applications plus complexes devs suggèrent souvent à l'aide d'un domain driven design pattern à la place (qui est ce que NHibernate facilite).

Le problème avec la table par classe de modèle, c'est que votre structure de base de données a une influence directe sur votre domaine de conception. Par exemple, disons que vous avez une table avec les colonnes suivantes pour organiser un client de l'adresse principale de l'information:

• StreetAddress
• Ville
• État
• Zip

Maintenant, disons que vous souhaitez ajouter des colonnes pour l'adresse postale du client en tant que bien de sorte que vous ajouter dans les colonnes suivantes de la table Clients:

• MailingStreetAddress
• MailingCity
• MailingState
• MailingZip

L'utilisation de LINQ to SQL, le Client de l'objet dans votre domaine aurait maintenant des propriétés de chacun de ces huit colonnes. Mais si vous étiez à la suite d'un domain driven design pattern, vous aurait probablement créé une Adresse de classe et a votre Client de classe de la tenue de deux propriétés de l'Adresse, une pour l'adresse postale et une adresse actuelle.

C'est un simple exemple, mais il démontre comment la table par classe de modèle peut conduire à un peu malodorante domaine. En fin de compte, c'est à vous. Encore une fois, pour des applications simples qui n'ont besoin que de base CRUD (create, read, update, delete) fonctionnalité, LINQ to SQL est idéal en raison de la simplicité. Mais personnellement, j'aime utiliser des NHibernate, parce qu'elle facilite un nettoyeur de domaine.

Edit: @lomaxx - Oui, l'exemple que j'ai utilisé était simpliste et pourrait avoir été optimisée avec LINQ to SQL. Je voulais le garder aussi simple que possible pour conduire à la maison le point. Le point reste cependant qu'il y a plusieurs scénarios où le fait d'avoir votre structure de base de données de déterminer la structure de votre domaine serait une mauvaise idée, ou au moins conduisent à sous-optimale OO design.

Answer 2

Deux points qui ont été manqués jusqu'à présent:

• LINQ to SQL ne fonctionne pas avec Oracle ou toute base de données en dehors de SqlServer. Cependant 3ème parties offrent un meilleur support pour Oracle, par exemple, devArt de dotConnect, DbLinq, Mindscape est LightSpeed et ALinq. (Je n'ai aucune expérience personnelle avec ces)

• Linq to NHibernate vous permet de vous servir Linq avec un Nhiberate, de sorte qu'il peut supprimer une raison de ne pas utiliser.

Aussi la nouvelle interface fluide à Nhibernate semble pour le rendre moins pénible à configurer Nhibernate de la cartographie. (La suppression de l'un des points de douleur de Nhibernate)

---

Mise à jour

Linq to Nhiberate est de mieux en Nhiberate v3 qui est actuellement en alpha. Ressemble Nhiberate v3 peut expédier vers la fin de cette année.

L' Entité Cadre de Travail que de .net 4 commence à ressembler à une vraie option.

Answer 3

@Kevin: je pense que le problème avec l'exemple que vous présentez est que vous utilisez une mauvaise conception de base de données. J'aurais pensé que tu créer une table client et une table d'adresses et normalisé les tables. Si vous faites cela, vous pouvez certainement utiliser Linq to SQL pour le scénario que vous êtes en train de suggérer. Scott Guthrie a une grande série de posts sur l'utilisation De Linq to SQL qui, je vous suggère fortement de vérifier.

Je ne pense pas que vous pourriez dire Linq et NHibernate complètent l'une l'autre, ce qui impliquerait qu'ils pourraient être utilisés ensemble, et, si cela est possible, vous êtes beaucoup mieux de choisir un et de s'y tenir.

NHibernate vous permet de mapper les tables de base de données à votre domaine d'objets dans une très flexible. Il permet également d'utiliser des HBL pour interroger la base de données.

Linq to SQL vous permet également de carte de votre domaine d'objets de la base de données cependant d'utiliser la syntaxe de requête Linq pour interroger la base de données

La principale différence ici est que la requête Linq syntaxe est vérifié au moment de la compilation par le compilateur afin de vous assurer que vos requêtes sont valides.

Certaines choses à connaître avec linq, c'est qu'il est uniquement disponible en .net 3.x et est pris en charge uniquement dans VS2008. NHibernate est disponible en 2.0 et 3.x ainsi que VS2005.

Certaines choses pour être au courant de NHibernate, c'est qu'il ne génère pas de votre domaine d'objets, ni de générer les fichiers de mappage. Vous devez faire cela manuellement. Linq peut
faire cela automatiquement pour vous.

Answer 4

NHibernate Fluent peut générer vos fichiers de mappage basé sur de simples conventions. Pas de XML-écrit et fortement typé.

J'ai récemment travaillé sur un projet, où nous avions besoin de changer de Linq to SQL pour NHibernate pour des raisons de performances. Surtout L2S la façon de matérialiser les objets semble plus lent que NHibernate de l'idem et de la gestion du changement est très lent aussi. Et il peut être difficile de tourner la gestion du changement off pour des scénarios spécifiques où il n'est pas nécessaire.

Si vous allez utiliser votre entités déconnectées du DataContext - dans WCF scénarios par exemple: vous vous êtes peut-être beaucoup de mal à se connecter au DataContext de nouveau pour mettre à jour les modifications. Je n'ai eu aucun problème avec qui avec NHibernate.

La chose que je vais manquer de L2S est surtout la génération de code qui maintient les relations à jour sur les deux extrémités des entités. Mais je pense qu'il y a des outils pour NHibernate à faire trop...

Answer 5

Pouvez-vous préciser ce que vous entendez par "LINQ"?

LINQ n'est pas une technologie d'accès aux données, c'est juste une fonctionnalité du langage qui prend en charge l'interrogation en tant que natif de construire. Il peut interroger n'importe quel modèle d'objet qui prend en charge des interfaces spécifiques (par exemple, IQueryable).

Beaucoup de gens se réfèrent à LINQ to SQL que LINQ, mais ce n'est pas du tout correct. Microsoft vient de sortir de LINQ to entities .NET 3.5 SP1. En outre, NHibernate a une LINQ interface, de sorte que vous pouvez utiliser LINQ et NHibernate d'accéder à vos données.