NHibernate contre LINQ vers SQL

Question

En tant que personne n'ayant utilisé aucune de ces technologies sur des projets du monde réel, je me demande si quelqu'un sait comment ces deux technologies se complètent et dans quelle mesure leurs fonctionnalités se chevauchent ?

Answer 1

LINQ to SQL vous oblige à utiliser le modèle table par classe.Les avantages de l'utilisation de ce modèle sont qu'il est rapide et facile à mettre en œuvre et qu'il nécessite très peu d'efforts pour faire fonctionner votre domaine sur la base d'une structure de base de données existante.Pour les applications simples, cela est parfaitement acceptable (et souvent même préférable), mais pour les applications plus complexes, les développeurs suggèrent souvent d'utiliser un conception axée sur le domaine pattern à la place (ce que facilite NHibernate).

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

• Adresse de la rue
• Ville
• État
• Fermeture éclair

Supposons maintenant que vous souhaitiez également ajouter des colonnes pour l'adresse postale du client afin d'ajouter les colonnes suivantes à la table Clients :

• AdresseRueMailing
• Ville de messagerie
• État de diffusion
• MailingZip

En utilisant LINQ to SQL, l'objet Customer de votre domaine aurait désormais des propriétés pour chacune de ces huit colonnes.Mais si vous suiviez un modèle de conception basé sur le domaine, vous auriez probablement créé une classe Address et demandé à votre classe Customer de contenir deux propriétés Address, une pour l'adresse postale et une pour son adresse actuelle.

C'est un exemple simple, mais il montre comment le modèle table par classe peut conduire à un domaine quelque peu malodorant.En fin de compte, c'est à vous de décider.Encore une fois, pour les applications simples qui ont juste besoin des fonctionnalités de base CRUD (créer, lire, mettre à jour, supprimer), LINQ to SQL est idéal en raison de sa simplicité.Mais personnellement, j'aime utiliser NHibernate car cela facilite un domaine plus propre.

Modifier:@lomaxx - Oui, l'exemple que j'ai utilisé était simpliste et aurait pu être optimisé pour bien fonctionner avec LINQ to SQL.Je voulais le garder aussi basique que possible pour faire comprendre le point.Il n'en reste pas moins qu'il existe plusieurs scénarios dans lesquels le fait que la structure de votre base de données détermine la structure de votre domaine serait une mauvaise idée, ou du moins conduirait à une conception OO sous-optimale.

Answer 2

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

• Linq à SQL ne fonctionne pas avec Oracle ou aucune base de données en dehors de SQLServer. Cependant, les tiers offrent un meilleur support pour Oracle, par ex. dotConnect de devArt, DbLinq, LightSpeed ​​de Mindscape et ALinq.(Je n'ai aucune expérience personnelle avec ceux-ci)

• Linq vers NHibernate Vous permet d'utiliser LINQ avec un NHIBERate, afin qu'il puisse supprimer une raison de ne pas utiliser.

Aussi le nouveau interface fluide avec Nhibernate semble rendre moins pénible la configuration du mappage de Nhibernate.(Suppression de l'un des points douloureux de Nhibernate)

---

Mise à jour

Linq to Nhiberate est meilleur dans Nhiberate v3 qui est maintenant disponible alpha.On dirait que Nhiberate v3 pourrait être disponible vers la fin de cette année.

Le Cadre d'entité à partir de .net 4, cela commence également à ressembler à une véritable option.

Answer 3

@Kévin :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 vous créeriez une table client et une table d'adresses et normaliseriez les tables.Si vous faites cela, vous pouvez certainement utiliser Linq To SQL pour le scénario que vous proposez.Scott Guthrie a un excellente série d'articles sur l'utilisation de Linq To SQL que je vous suggère fortement de consulter.

Je ne pense pas que l'on puisse dire que Linq et NHibernate se complètent, car cela impliquerait qu'ils pourraient être utilisés ensemble, et bien que cela soit possible, il vaut mieux en choisir un et s'y tenir.

NHibernate vous permet de mapper vos tables de base de données sur vos objets de domaine de manière très flexible.Il vous permet également d'utiliser HBL pour interroger la base de données.

Linq to SQL vous permet également de mapper vos objets de domaine à la base de données, mais il utilise la syntaxe de requête Linq pour interroger la base de données.

La principale différence ici est que la syntaxe des requêtes Linq est vérifié au moment de la compilation par le compilateur pour garantir que vos requêtes sont valides.

Certaines choses à prendre en compte avec Linq sont qu'il n'est disponible que dans .net 3.x et n'est pris en charge que dans VS2008.NHibernate est disponible en 2.0 et 3.x ainsi que VS2005.

Certaines choses à prendre en compte avec NHibernate sont qu'il ne génère pas vos objets de domaine, ni les fichiers de mappage.Vous devez le faire manuellement.Linq peut
faites-le automatiquement pour vous.

Answer 4

Fluent NHibernate peut générer vos fichiers de mappage basés sur des conventions simples.Pas d'écriture XML et fortement typé.

J'ai récemment travaillé sur un projet dans lequel nous devions passer de Linq To SQL à NHibernate pour des raisons de performances.En particulier, la manière de matérialiser les objets de L2S semble plus lente que celle de NHibernate et la gestion des changements est également assez lente.Et il peut être difficile de désactiver la gestion du changement pour des scénarios spécifiques où elle n’est pas nécessaire.

Si vous envisagez d'utiliser vos entités déconnectées du DataContext - dans des scénarios WCF par exemple - vous pourriez avoir beaucoup de mal à les reconnecter au DataContext pour mettre à jour les modifications.Je n'ai eu aucun problème avec NHibernate.

Ce qui me manquera dans L2S, c'est principalement la génération de code qui maintient les relations à jour aux deux extrémités des entités.Mais je suppose qu'il existe également des outils permettant à NHibernate de le faire...

Answer 5

Pouvez-vous clarifier ce que vous entendez par « LINQ » ?

LINQ n'est pas une technologie d'accès aux données, c'est simplement une fonctionnalité de langage qui prend en charge les requêtes en tant que construction native.Il peut interroger n'importe quel modèle objet prenant en charge des interfaces spécifiques (par ex.IQueryable).

Beaucoup de gens appellent LINQ To SQL LINQ, mais ce n'est pas du tout correct.Microsoft vient de publier LINQ To Entities avec .NET 3.5 SP1.De plus, NHibernate dispose d'une interface LINQ, vous pouvez donc utiliser LINQ et NHibernate pour accéder à vos données.

Answer 6

Par LINQ, je suppose que vous entendez LINQ to SQL car LINQ, en lui-même, n'a aucune base de données « activités » qui lui est associée.C'est juste un langage de requête qui contient une multitude de sucre syntaxique pour lui donner un aspect SQL.

Dans les exemples les plus élémentaires, NHibernate et LINQ to SQL semblent tous deux résoudre le même problème.Une fois que vous avez réussi, vous réalisez vite que NHibernate prend en charge de nombreuses fonctionnalités qui vous permettent de créer des modèles de domaine vraiment riches.Il existe également un projet LINQ to NHibernate qui vous permet d'utiliser LINQ pour interroger NHibernate de la même manière que vous utiliseriez LINQ to SQL.

Answer 7

Séparons d’abord deux choses différentes :La modélisation de base de données se préoccupe des données tandis que la modélisation objet se préoccupe des entités et des relations.

L'avantage de Linq-to-SQL est de générer rapidement des classes à partir du schéma de base de données afin qu'elles puissent être utilisées comme objets d'enregistrement actif (voir la définition du modèle de conception d'enregistrement actif).

L'avantage de NHibernate est de permettre une flexibilité entre votre modélisation objet et la modélisation de base de données.La base de données peut être modélisée pour refléter au mieux vos données en tenant compte des performances par exemple.Tandis que votre modélisation objet reflétera au mieux les éléments de la règle métier en utilisant une approche telle que Domain-Driven-Design.(voir commentaire de Kevin Pang)

Avec des bases de données héritées avec des conventions de modélisation et/ou de dénomination médiocres, Linq-to-SQL reflétera ces structures et noms indésirables dans vos classes.Cependant, NHibernate peut masquer ce gâchis grâce aux mappeurs de données.

Dans les nouveaux projets où les bases de données ont un bon nommage et une faible complexité, Linq-to-SQL peut être un bon choix.

Cependant, vous pouvez utiliser NHibernate courant avec mappages automatiques dans ce même but avec le mappage comme convention.Dans ce cas, vous ne vous inquiétez pas des mappeurs de données avec XML ou C# et laissez NHibernate générer le schéma de base de données à partir de vos entités sur la base d'une convention que vous pouvez personnaliser.

D'un autre côté, la courbe d'apprentissage de Linq-to-SQL est plus petite que celle de NHibernate.

Answer 8

Ou vous pouvez utiliser le projet Castle ActiveRecords.Je l'utilise depuis peu de temps pour créer du nouveau code pour un projet existant.Il utilise NHibernate et fonctionne sur le modèle d'enregistrement actif (surprenant étant donné son nom que je connais).Je n'ai pas essayé, mais je suppose qu'une fois que vous l'avez utilisé, si vous ressentez le besoin de passer directement au support NHibernate, ce ne serait pas de trop de le faire pour une partie ou la totalité de votre projet.

Answer 9

Comme vous avez écrit "pour une personne qui n'a utilisé aucun des eux" Linq à SQL est facile à utiliser afin que quiconque puisse l'utiliser facilement, il prend également en charge les procédures, ce qui aide la plupart du temps.Supposons que vous souhaitiez obtenir des données à partir de plus d'une table, puis rédigez une procédure et faites glisser cette procédure vers le concepteur et cela créera tout pour vous, supposons que le nom de votre procédure est "Customer_Order_lineItem" qui récupérera l'enregistrement de tous ces trois tableaux, puis écrivez simplement

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

vous pouvez également utiliser votre objet records dans la boucle foreach, ce qui n'est pas pris en charge par NHibernate