EntityFramework withour EDMX

Question

Nous sommes sur le point de commencer à utiliser EF comme ORM. Nous avons notre propre MetaData représentant la strucure de base de données et nous générerons tout ce dont nous avons besoin. Nous nous demandons s'il faut utiliser la "vieille" approche EDMX, ou utiliser la nouvelle approche libre EDMX (avec DbSet et DbContext). Comme nous faisons notre propre génération de code/edmx, il semble étrange de générer un EDMX, puis de générer des objets et du contexte.

Je ne vois pas grand-chose à propos de l'approche gratuite EDMX. Est-ce que c'est utilisé par n'importe qui? Quelqu'un d'expérience peut-il partager ses impressions? Y a-t-il des limites connues? Y a-t-il des avantages et des inconvénients?

Asher

Answer 1

Demandez-vous si quelqu'un utilise le code d'abord? :) En vérifiant le nombre de questions dans entity-framework-4.1 et code-first et ef-code-first Je suppose que les gens l'utilisent beaucoup. Il y avait plusieurs questions à propos de code-first x non code-first. Certains d'entre je répondis:

• EF POCO code only VS EF POCO with Entity Data Model
• EF Model First or Code First Approach?
• EF 4.1 Code-first vs Model/Database-first

En général, quatre approches:

• Le premier modèle (base de données générée à partir EDMX)
• Base de données F IRST (EDMX générée à partir de la base de données)
• code première (base de données générée à partir de la cartographie de code)
• base de données d'abord avec la cartographie de code (mappage de code créé manuellement pour base de données existante ou mappage mises à jour manuellement généré par EF Power Tools CTP)

Sélection de l'approche dépend généralement de la façon dont vous voulez développer l'application (comme décrit dans les réponses liées). Cela dépend également si vous souhaitez utiliser l'API ObjectContext ou l'API DbContext. Le premier est généralement utilisé avec les deux premières approches (mais le secret est qu'il devrait fonctionner avec le code d'abord aussi bien) le plus tard avec tous.

premier code a des limites - il ne supporte pas toutes les fonctionnalités de cartographie EDMX ne par exemple:

• cartographie des procédures stockées (cela ne signifie pas que vous ne pouvez pas exécuter SP lorsque vous utilisez le code premier)
• fonctions SQL cartographie
• fonctionnalités avancées EDMX comme la définition des requêtes, des vues de la requête, les fonctions définies par modèle
• etc.

Ce que je ne comprends pas, c'est pourquoi essayez-vous de combiner votre outil de génération de code avec EF. Utilisez vos affaires ou utilisez les trucs d'EF. Vous éviterez les complications et les incompatibilités.