Lorsque vous choisissez un ORM, est-ce que LINQ to SQL ou LINQ to Entities est préférable à NHibernate?

Question

Je trouve que je peux faire plus avec NHibernate et même Castle qu'avec Linq to Entities ou linq to SQL.

Suis-je fou?

Answer 1

Non, vous n'êtes pas fou. nHibernate est un mappeur OR complet, Linq to SQL et Linq to Entities ne mettent pas en oeuvre tout ce que vous attendez d’un mappeur OR et s’adressent à un groupe de développeurs légèrement différent.

Mais ne vous laissez pas décourager par linq. Linq est toujours une bonne idée .. Essayez Linq pour nHibernate: -)

Answer 2

Le gros inconvénient de NHibernate, Castle, etc., est qu’ils ne sont pas vraiment légers (surtout NHibernate.)

Linq to SQL est bon pour un ORM d’utilisation légère et limité.

Answer 3

J'ai utilisé NHibernate et LINQ to SQL. De mon point de vue, cela dépend du projet. Si j'avais besoin de quelque chose de rapide, je choisirais L2S. C'est tellement simple de créer le mappage dbml et de commencer à l'utiliser. Si je développe une solution d'entreprise de plus haut niveau, je rechercherais l'ORM - NHibernate, une technologie éprouvée et éprouvée, je trouve la journalisation & amp; fonctionnalités de transaction simples à utiliser.

LINQ to SQL a une courbe d’apprentissage relativement courte, NHibernate a une courbe d’apprentissage beaucoup plus abrupte.

LINQ to SQL ne prend en charge que SQL Server. Par conséquent, si vous avez une base de données Oracle, la décision est déjà prise - NHibernate.

Je vous conseillerais de vérifier http://www.summerofnhibernate.com/ pour d'excellents screencasts sur l'apprentissage. NHibernate.

Answer 4

Une chose à garder à l’esprit est que NHibernate peut être un élément essentiel à configurer, en particulier du fait qu’il est principalement basé sur des fichiers de configuration XML en raison de ses racines en tant que Hibernate original.

NHibernate Fluent contribue à rendre la situation moins pénible.

Linq s’accorde certes bien avec la façon générale de travailler avec .NET.

Answer 5

  

Blockquote Linq s’accorde certes bien avec la façon générale dont fonctionne le NET.

Oui, ce genre de sentiment me fait peur. Le contenu RAD intégré dans .net n’est PAS le fonctionnement de dot net, c’est juste un ensemble d’outils permettant d’obtenir des prototypes. .NET nous permet de faire des applications DDD complètes, avec des niveaux élevés de cohésion, de séparer les préoccupations, et nous permet d’écrire du code découplé, malgré toutes les tentatives faites par ms pour coupler des choses. Je ne suis absolument pas d'accord avec le fait que .net aime être couplé, les outils certian aiment être couplés, j'inclurai linq to sql dans cette mêlée. linq to sql détruit l’idée de disposer d’un modèle de domaine séparé. Je craque d’utiliser mon schéma de base de données comme objets de modèle sous-jacents. Des outils ORM appropriés devraient nous permettre de modéliser d'abord notre domaine, puis de lier notre base de données relationnelle à ces modèles. PAS l'inverse.

Answer 6

Je n’ai pas essayé Entity Framework, mais je recommanderais certainement NHibernate à Linq en SQL; La principale raison pour laquelle je peux donner est simplement le contrôle. Linq to SQL aime avoir beaucoup plus de contrôle sur tout, en chargeant l'objet et en conservant toutes sortes d'informations de suivi sur l'objet. Si vous sérialisez / désérialisez, les informations de suivi peuvent être perdues et des choses étranges peuvent se produire lors de la sauvegarde. NHibernate fonctionne plus comme un référentiel devrait: vous lui remettez l’objet de votre choix (que vous avez configuré pour le comprendre, bien sûr), et il le range dans la base de données, quel que soit ce que vous avez fait avec.