Question

J'essaie de décider de la meilleure stratégie pour accéder à la base de données. Je comprends qu’il s’agit d’une question générique et qu’il n’ya pas une seule bonne réponse, mais je vais vous donner des directives sur ce que je recherche. Ces dernières années, nous avons utilisé notre propre cadre de persistance, qui, bien que limité, a également servi. Cependant, des améliorations majeures sont nécessaires et je me demande si je devrais utiliser cette méthode ou utiliser l’un des cadres existants. Les critères que je recherche, par ordre d'importance, sont les suivants:

  1. Le code client doit fonctionner avec des objets propres, sans aucune connaissance de la base de données. Lorsque vous utilisez notre infrastructure personnalisée, le code client ressemble à:

    SessionManager session = new SessionManager (); Order order = session.CreateEntity (); order.Date = DateTime.Now; // Définir d'autres propriétés OrderDetail detail = order.AddOrderDetail (); detail.Product = produit; // Autres propriétés

    // Valider toutes les modifications maintenant session.Commit ();

  2. Devrait être aussi simple que possible et ne pas être "trop ??souple". Nous avons besoin d’une manière unique de faire la plupart des choses.

  3. Doit avoir un bon support pour la programmation orientée objet. Devrait gérer les relations un-à-plusieurs et plusieurs-à-plusieurs, devrait gérer l'héritage, la prise en charge du chargement paresseux.
  4. Il est préférable que la configuration soit basée sur XML.

Avec mes connaissances actuelles, je vois les options suivantes:

  1. Améliorer notre cadre actuel - le problème, c’est que des efforts considérables sont nécessaires.
  2. ADO.NET Entity Framework - Ne comprenez pas bien, mais semble trop compliqué et contient de mauvaises critiques.
  3. LINQ to SQL - Ne gère pas correctement les pratiques orientées objet.
  4. nHibernate - Cela semble une bonne option, mais certains utilisateurs signalent trop d’erreurs archaïques.
  5. SubSonic - Dans une courte introduction, cela semble trop flexible. Je ne veux pas ça.

Que proposerez-vous?

EDIT:

Merci Craig pour cette réponse complexe. Je pense que cela aidera davantage si je donne plus de détails sur notre framework personnalisé. Je cherche quelque chose de similaire. Voici comment fonctionne notre framework personnalisé:

  1. Il est basé sur DataSets. La première chose à faire est donc de configurer le DataSets et écrivez les requêtes dont vous avez besoin.
  2. Vous créez un fichier de configuration XML qui spécifie comment les tables DataSet se mappent aux objets et spécifie également des associations entre eux (prise en charge de tous les types d'associations). 3.Un outil personnalisé analyse la configuration XML et génère le code nécessaire. 4.Les classes générées héritent d'une classe de base commune.

Pour être compatible avec notre framework, la base de données doit répondre à ces critères:

  1. Chaque table devrait avoir une seule colonne en tant que clé primaire.
  2. Toutes les tables doivent avoir une clé primaire du même type de données générée sur le client.
  3. Pour gérer l'héritage, seul l'héritage d'une table est pris en charge. De plus, le fichier XML offre presque toujours un seul moyen de réaliser quelque chose.

Ce que nous voulons soutenir maintenant, c'est:

  • Supprimez la dépendance de DataSets. Le code SQL doit être généré automatiquement, mais la structure NE doit PAS générer le schéma. Je souhaite contrôler manuellement le schéma de la base de données.
  • Prise en charge plus robuste des hiérarchies d'héritage.
  • Intégration facultative avec LINQ.

J'espère que ce que je recherche est plus clair maintenant.

Était-ce utile?

La solution

  

Améliorer notre cadre actuel - le problème est qu’il faut déployer beaucoup d’efforts

Dans votre question, vous n'avez pas expliqué pourquoi vous devriez réécrire les fonctionnalités disponibles dans de nombreux autres endroits. Je suggérerais que réinventer un ORM ne soit pas une bonne utilisation de votre temps, sauf si vous avez des besoins uniques pour l'ORM que vous n'avez pas spécifiés dans votre question.

  

ADO.NET Entity Framework

Nous utilisons Entity Framework dans le monde réel, un logiciel de production. Compliqué? Pas plus que la plupart des autres ORM, pour autant que je sache, ce qui revient à dire "assez compliqué". Cependant, il est relativement nouveau et, de ce fait, l'expérience et la documentation de la communauté sont moindres. que quelque chose comme NHibernate. Le manque de documentation peut donc sembler compliqué.

Entity Framework et NHibernate adoptent des approches très différentes pour résoudre le problème de la réduction de la fracture relation-objet. J'ai écrit à ce sujet de manière beaucoup plus détaillée dans cet article de blog . Vous devez déterminer quelle approche est la plus logique pour vous.

De nombreux commentaires ont été formulés sur Entity Framework, à la fois positifs et négatifs. Certains sont fondés et certains semblent provenir de personnes qui proposent d'autres solutions. Les critiques bien fondées incluent

  • Absence de prise en charge de POCO. Ce n'est pas un problème pour certaines applications, c'est un problème pour d'autres. La prise en charge de POCO sera probablement ajoutée dans une prochaine version, mais aujourd’hui, IPOCO est le meilleur que puisse proposer Entity Framework.
  • Un fichier de mappage monolithique. Cela n'a pas été un gros problème pour nous, car nos métadonnées ne sont pas en constante évolution.

Cependant, certaines des critiques me semblent manquer à la forêt pour les arbres. C'est-à-dire qu'ils parlent de fonctionnalités autres que les fonctionnalités essentielles du mappage relationnel objet, ce qu'Entity Framework nous a prouvé qu'il fonctionne très bien.

  

LINQ to SQL - Ne gère pas correctement les pratiques orientées objet

Je suis d'accord. De plus, je n'aime pas le focus SQL Server.

  

nHibernate - Cela semble une bonne option, mais certains utilisateurs signalent trop d’erreurs archaïques.

Eh bien, ce qui est bien avec NHibernate, c’est qu’il existe une communauté très dynamique autour de lui, et quand vous rencontrez ces erreurs ésotériques (et croyez-moi, Entity Framework a aussi son lot d’erreurs ésotériques; le territoire), vous pouvez souvent trouver des solutions très facilement. Cela dit, je n'ai pas beaucoup d'expérience personnelle avec NHibernate au-delà de l'évaluation que nous avons faite, qui nous a conduit à choisir Entity Framework. Je vais donc laisser d'autres personnes ayant une expérience plus directe commenter.

  

SubSonic - À partir d’une brève introduction, cela semble trop souple. Je ne veux pas ça.

Bien entendu, SubSonic est bien plus qu’un ORM et les utilisateurs de SubSonic ont la possibilité de choisir une autre implémentation d’ORM au lieu d’utiliser ActiveRecord de SubSonic. En tant que cadre d'application Web, je le considérerais. Cependant, sa fonctionnalité ORM n’est pas sa raison d’être et je pense qu’il est raisonnable de penser que la partie ORM de SubSonic recevra moins d’attention que les frameworks ORM dédiés.

Autres conseils

LLBLGen est un très bon outil de gestion des ressources manuelles qui fera presque tout ce dont vous avez besoin.

iBATIS est ce que je préfère parce que vous maîtrisez mieux le code SQL

.

Objets de persistance Developer Express ou XPO , comme son nom l'indique. Je l'utilise depuis 3 ans. Il fournit tout ce dont vous avez besoin, sauf qu’il est commercial et que vous vous associez à une autre (entreprise unique) pour votre développement. En dehors de cela, Developer Express est l’un des meilleurs fournisseurs de composants et d’infrastructure pour la plate-forme .NET.

Un exemple de code XPO serait: 

using (UnitOfWork uow = new UnitOfWork())
{
  Order order = new Order(uow);
  order.Date = DateTime.Now();
  uow.CommitChanges();
}

Je suggère de consulter ActiveRecord de Castle . Je n'ai pas l'expérience de la production avec cela, je viens de jouer avec leur exemple d'application. Cela semble très facile de travailler avec, mais je ne le connais pas assez bien pour savoir si cela répond à toutes vos exigences

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top