Quel ORM pour .net dois-je utiliser?

Je suis relativement nouveau dans .NET et j’utilise Linq2Sql depuis presque un an, mais certaines des fonctionnalités que je recherche manquent.

Je vais commencer un nouveau projet dans lequel je veux utiliser un ORM avec les caractéristiques suivantes:

  • Cela doit être très productif, je ne veux pas m’occuper de la couche d’access pour sauvegarder ou récupérer des objects depuis ou vers la firebase database, mais cela devrait me permettre d’ajuster facilement n’importe quel object avant de le valider réellement; cela devrait aussi me permettre de travailler facilement avec un schéma de firebase database changeant
  • Cela devrait me permettre d’étendre les objects mappés à partir de la firebase database, par exemple pour leur append des atsortingbuts virtuels (des colonnes virtuelles à une table).
  • Il doit être (au moins presque) agnostique à la firebase database, cela devrait me permettre de travailler avec différentes bases de données de manière transparente
  • Il ne doit pas avoir trop de configuration ou doit être basé sur des conventions pour que cela fonctionne
  • Cela devrait me permettre de travailler avec Linq

Alors, connaissez-vous un ORM que je pourrais utiliser? Merci de votre aide.

EDIT Je sais qu’une option est d’utiliser NHibernate. Cela apparaît comme le standard de facto pour les applications d’entreprise, mais il semble également que ce ne soit pas très productif en raison de sa courbe d’apprentissage approfondie. En d’autres termes, j’ai lu dans un autre billet ici dans SO que cela ne s’intègre pas bien avec Linq. Est-ce que tout cela est vrai?

Peut-être que votre meilleur choix est d’utiliser NHibernate . C’est sans doute le meilleur “standard de l’indussortinge” en ce qui concerne les ORM commerciaux et open source. Cela fait longtemps que la société est devenue vraiment stable, elle est utilisée dans de nombreuses entresockets, est basée sur le plus connu Hibernate (java), mais a été entièrement réécrite pour tirer le meilleur parti des fonctionnalités .NET.

Inconvénients de NHibernate

On dirait que je suis un partisan de NHibernate. Peut-être que je suis. Mais NHibernate a un inconvénient: sa courbe d’apprentissage est abrupte. Il est parfois décourageant de s’habituer aux nombreuses possibilités. Choisir la bonne pratique ou la “meilleure” pratique adaptée à votre situation peut être décourageant, même pour les développeurs expérimentés. Mais c’est le prix à payer pour un ORM de niveau entreprise capable de pratiquement tout.

NHibernate avec des roches FluentNHibernate

Bon nombre de ces inconvénients et problèmes d’installation s’évaporent dès que vous commencez à utiliser Fluent Nhibernate , personnellement, je ne m’en passe plus vraiment car il supprime tous les ennuis de NHibernate à la fois (presque).

Il est très simple de travailler avec NHibernate: il suffit d’écrire vos entités en tant que POCO et de les charger complètement automatiquement pour créer votre firebase database, les associations, etc. (ou ne créez pas le schéma s’il existe déjà). Configurez votre firebase database en utilisant la syntaxe Fluent. Une configuration très simple peut sembler aussi basique que celle-ci:

// part of a default abstract setup class I use public ISessionFactory CreateSessionFactory() { return Fluently.Configure() .Database( MsSqlConfiguration.MsSql2008 .ConnectionSsortingng(c => c.Server(this.ServerName) .Database(this.DatabaseName) .Username(this.Username) .Password(this.Password) ) ) .Mappings(m => m.AutoMappings.Add(AutoMap.AssemblyOf() // loads all POCOse .Where(t => t.Namespace == this.Namespace)) // here go the associations and constraints, // (or you can annotate them, or add them later) ) .ExposeConfiguration(CreateOrUpdateSchema) .BuildSessionFactory(); } // example of an entity // It _can_ be as simple as this, which generates the schema, the mappings ets // but you still have the flexibility to expand and to map using more complex // scenarios. It is not limited to just tables, you can map views, stored procedures // create sortingggers, associations, unique keys, constraints etc. // The Fluent docs help you step by step public class User { public virtual int Id { get; private set; } // autogens PK public virtual ssortingng Name { get; set; } // augogens Name col public virtual byte[] Picture { get; set; } // autogens Picture BLOB col public virtual List Settings { get; set; } // autogens to many-to-one } public class UserSettings { public virtual int Id { get; private set: } // PK again public virtual int UserId { get; set; } // autogens FK public virtual User { get; set; } // autogens OO-mapping to User table } 

qui prend toutes les entités POCO et les mappe automatiquement, crée la configuration de l’ORM et construit le schéma dans la firebase database, à condition que l’utilisateur dispose des droits suffisants. Une capacité très puissante de Fluent (et de NH dans une moindre mesure) consiste à mettre à jour un schéma de firebase database lorsque vous apportez des modifications.

Autres aides à NHibernate

De plus, il existe de nombreux outils de génération automatique (y compris MyGeneration open source) qui peuvent extraire vos schémas de firebase database d’une simple connexion ODBC ou autre et les transformer en classes d’entités, associations et fichiers de configuration HBM corrects. Nombre de ces outils sont des aides à la conception (partiellement) graphiques.

Utilisez S # arp pour appliquer les meilleures pratiques de MVC + NH + NUnit

Assurez-vous de lire les meilleures pratiques de NHibernate . Il apporte les génériques et DAO au niveau suivant. Vous pouvez également passer à la chasse et plonger profondément dans S # arp ( télécharger ), un cadre qui impose toutes ces meilleures pratiques et ajoute NUnit au mélange.

Avant de commencer à utiliser une nouvelle technologie, je souhaite généralement qu’elle soit bien couverte. NHibernate et Hibernate ne manquent pas ici. De nombreux livres expliquent (N) Hibernate de débutant à professionnel, les livres blancs sont abondants et la documentation sur les outils est plutôt excellente.

À propos de LINQ et NH

LINQ et NHibernate se sont toujours bien associés grâce à tous les types de ICollection<> utilisés dans les mappages many-to-X et autres associations, mais nécessitent la récupération préalable des données, ce qui nécessite une bonne conception (le cache aide ici), sinon ça va mal se comporter. Cela a été considéré comme un point sensible de NH depuis que LINQ a vu le jour.

Heureusement, il y a maintenant un nouvel enfant en ville: NHibernate-LINQ , qui mappe les requêtes LINQ aux requêtes ICriteria avant de les soumettre. Les requêtes ICriteria sont bien mises en cache et cette combinaison avec LINQ est à la fois très puissante et très performante. NH-LINQ fait maintenant partie de la dissortingbution standard.

Avertissement

J’ai utilisé NHibernate pendant presque dix ans (d’abord Java, plus tard .NET). J’ai flirté avec d’autres sources commerciales et open source d’ORM, mais je suis toujours retourné à NH (à moins que la politique de l’entreprise ne l’exige différente, mais c’était rare). Cette histoire peut sembler un peu biaisée mais l’espace ici est trop court pour entrer dans des détails atroces sur la façon dont NHibernate se compare à d’autres technologies.

Il est fort possible que d’autres ORM répondent mieux à vos besoins, en particulier si vous n’envisagez jamais de l’utiliser dans des situations complexes comportant plusieurs bases de données, plusieurs serveurs de bases de données ou des environnements difficiles à mapper sur OO. Pour moi, NH brille parce qu’il ne me limite en aucune manière et qu’il prend en charge une ingénierie complète aller-retour, mais votre choix peut s’avérer différent si les fonctionnalités des MRO plus légères dont il est question ici pèsent plus lourd pour vous.

Mise à jour: exemple de code ajouté
Mise à jour: exemple de code développé, fautes de frappe et libellés corrigés
Mise à jour: petits chapitres, ajout d’une partie LINQ, ajout d’une partie d’exclusion de responsabilité

Pourquoi ne pas regarder le subsonique ? J’aime celui-ci par rapport aux autres, car il est léger, mappe de manière transparente au schéma de firebase database (utilise ActiveRecord) et répond à toutes vos exigences.

Cela doit être très productif.

Je pense que c’est le travail de chaque ORM? Avec subsonic, vous pouvez utiliser le contrôleur (pour la liaison de données) ou simplement exécuter la méthode Save sur n’importe quel object ORM.

Cela devrait me permettre d’étendre les objects

L’extension des classes générées est facile, elles sont toutes définies comme des partiels. Et vous pouvez même éditer les modèles. (Ce sont des modèles T4 que vous incluez dans votre projet, vous permettant ainsi de contrôler totalement le mode et les éléments générés.)

Il doit être (au moins presque) agnostique à la firebase database

Je pense que c’est un peu fondamental pour n’importe quel ORM. Subsonic supporte beaucoup de bases de données dont les plus connues sont: Oracle, mySql, MsSql, SqlLite, SqlCE. Vous pouvez consulter la liste de support de firebase database ici .

Il ne doit pas avoir autant de configuration ou doit être basé sur des conventions

Oui, il est absolument conventionnel de configurer ou d’opinion comme ils l’appellent. Pour un résumé des conventions, regardez ici .

Cela devrait me permettre de travailler avec Linq

Absolument, depuis la version 3.0, Linq est supporté.

Pour une comparaison entre nhibernate, LinqToSql et subsonic, lisez ceci. Il s’agit en fait d’une comparaison juste et actualisée, qui souligne explicitement les différences de visions entre les différents ORM.

Ce qui me manque dans le subsonique:

  • Support UnitOfWork (vous pouvez résoudre ce problème en utilisant le support pour les transactions.)

  • Prise en charge d’IdentityMap (vos objects sont mis en cache dans une certaine étendue (domaine d’application, menace, contexte de requête Web, durée de vie de la page, …)) Bien que vous puissiez déterminer si cela est censé faire partie de l’ORM ou d’une couche de mise en cache.

J’ai entendu hibernate soutenu les deux.

Je suggère de vérifier NHibernate.

https://www.hibernate.org/343.html

Compte tenu de vos besoins, je vous conseillerais de consulter Mindscape LightSpeed . Il supporte environ huit ou neuf bases de données différentes et est basé sur des conventions (avec des options de configuration), il est donc très facile à configurer. Il a un fournisseur LINQ. Il vous permet d’étendre les classes avec vos propres propriétés et méthodes: en particulier, il vous permet de découpler le modèle persistant (les champs) de l’API (les propriétés et les méthodes) sans rompre la convention sur l’approche de configuration.

J’ai utilisé Entity Framework pour quelques projets et cela m’a vraiment plu. La première version contenait certes des problèmes, en particulier la manière dont elle traitait les clés étrangères et les procédures stockées, mais la version 2, qui est en version bêta et qui fait partie de VS 2010, semble très prometteuse.

Pour donner suite à certaines des réponses données ici, NHibernate Linq est le fer de lance de l’incroyablement prolifique Oren Eini, AKA Ayende Rahien.

http://ayende.com/Blog/archive/2009/07/26/nhibernate-linq-1.0-released.aspx

Je ne l’ai pas utilisé, mais c’est très impressionnant. On dirait qu’à un certain niveau, cela pourrait même remplacer LINQ pour SQL.

Man..J’irais avec le cadre de l’ entité . Il supporte Linq. Le framework d’entité 4.0 présente des améliorations de performances majeures par rapport à 3.5. Il a tout ce dont vous avez besoin dans votre message. EF est plus qu’un ORM, c’est un cadre. Je pense que nhibernate est une blague par rapport au cadre M $ entity. Nhibernate a vraiment laissé tomber la balle pour ne pas avoir compris intellisense et avoir rendu l’installation plus facile.

De nombreuses entresockets ont également adopté le cadre des entités. Entity Framework peut prendre en charge toute firebase database pouvant être exécutée sous Windows, car il dispose d’une fonctionnalité permettant à tout fournisseur de créer un fournisseur. Faites-vous une faveur et allez avec EF.

Vous pouvez également consulter LLBLGen. Même s’il manque un nom vif, il possède toutes les fonctionnalités que vous avez mentionnées:

Ce sont des pilotes pour la plupart des versions de firebase database, Oracle, SQL et autres. Il supporte Linq, en ce sens que vous pouvez utiliser Linq pour interroger les objects générés par LLBLgen. Il vous permet d’étendre les objects générés, ce sont toutes des classes partielles.

Je sais que cette question a presque 8 ans, mais au moins, s’il est difficile de répondre à cette question, ils auront une image plus complète des ORM disponibles.

Nous utilisons Dapper pour accéder à la firebase database. C’est très léger. C’est extrêmement rapide. Je continue d’écrire en SQL (ce qui est ma préférence). Il mappe automatiquement les données renvoyées dans des objects, même un object dynamic. Vous pouvez append des extensions qui vont insérer, mettre à jour, etc. sans avoir besoin de SQL. Vous pouvez donc le construire pour imiter de plus près un ORM complet.

Une fois que vous commencez à l’utiliser, vous serez surpris de la façon dont vous avez vécu sans elle. Il devrait être livré avec le framework .NET.

La firebase database est agnostique, MAIS le SQL que vous écrivez peut ne pas être. Donc, si vous écrivez votre propre SQL, vous devez vous assurer que cela fonctionne sur vos bases de données cibles.