58 votes

ADO.NET DbContext Generator vs Générateur d'entité Poco ADO.NET (ObjectContext)

Je suis sur le point de commencer la mise en œuvre de l'accès aux données de l'infrastructure d'un projet qui a été conçu avec une approche à la DDD (c'est ma première tentative sur DDD, alors soyez gentil ;-) ).

Je vais être en utilisant Entity Framework. Jusqu'à présent, je regardais dans la méthode enseignée par Julie Lerman sur son grand livre, la Programmation Entity Framework, où ADO.NET POCO Entité Générateur est utilisé, avec quelques changements de modèles de T4 et un peu plus de code personnalisé.
Aujourd'hui, j'ai commencé à lire des articles sur EF4.1 et de la ADO.NET DbContext Générateur, à l'aide de la Base de données de la Première approche, et je suis en train de décider avec qui dois-je aller.

DbContext et EF4.1 l'approche DDD semble être une jolie, manière plus propre que les Entités POCO, mais je crains que cela pourrait conduire à certains problèmes dans un futur proche, puisque EF4.1 est encore en RC.

À partir de ADO.NET blog de l'équipe, je sais que EF4.1 ne pas comprendre:

  • Prise en charge des énumérations
  • Type de données spatiales de soutien
  • Procédure stockée soutien dans le Premier Code,
  • Assistance à la Migration dans le Premier Code,
  • Personnalisable conventions dans le Premier Code,

De ma compréhension, étant donné que j'utiliserai la Première Base de données il y a un petit nombre de fonctionnalités qui n'étaient pas inclus.

En conclusion, ma question est:
Puis-je remplacer les Entités POCO Générateur avec EF4.1 DbContext Générateur?

54voto

Ladislav Mrnka Points 218632

À partir d'un point de vue de "nettoyer" la création d'entités POCO, il n'y a pas de différence entre les deux générateurs. Les deux générateurs produisent les mêmes entités, cependant, ADO.NET POCO Entité Générateur est basé sur ObjectContext de l'API, alors que ADO.NET DbContext Générateur est basé sur DbContext de l'API.

DbContext de l'API a quelques très belles nouvelles fonctionnalités (Local, une Requête sur une propriété de navigation, etc.) et de l'API est en quelque sorte simplifié mais en même temps, il semble que quelques fonctions utilisées dans le ObjectContext API sont manquants dans DbContext API (ou au moins, il n'a pas été exploré encore assez).

4.1 EF RC est le go-live version. Cela signifie que vous pouvez construire une application réelle parce que l'API ne changera pas dans RTW (uniquement les bugs seront corrigés). Également de RETOUR au travail devrait être le mois prochain donc je pense que vous ne serez pas prêt avec votre demande avant la version finale est expédiée.

ObjectContext de l'API ou de l'API DbContext? ObjectContext API est beaucoup mieux couverts par des documents et des billets de blog. Vous pouvez trouver beaucoup d'exemples à ce sujet. Aussi ses limites sont déjà bien connues. DbContext API est la nouvelle version. Une très prometteur de presse, principalement en raison de la code-première approche. Il y a encore un nombre très limité d'articles de blog, pas de livre et de l'API n'est pas avéré suffisant. Donc, cela dépend si vous êtes prêt à se battre avec la nouvelle API? Si non, alors ObjectContext API est toujours un bon choix parce que vous n'avez pas besoin de code-première approche.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X