CodeFirst est-il destiné à des applications à grande échelle?

J'ai lu sur Entity Framework, en particulier, EF 4.1 et en suivant ce lien ( http://weblogs.asp.net/scottgu/archive/2010/07/07/16/code-first-development-with-entity- framework-4.aspx ) et son guide sur Code First.

Je le trouve soigné mais je me demandais, Code First est-il censé être juste une solution pour un développement rapide où vous pouvez simplement vous lancer sans trop de planification ou est-il réellement destiné à être utilisé pour des applications à grande échelle?

J'ai peut-être des détracteurs, mais quand j'ai lu certains de ces articles de Hanselman et Gutherie, puis lu le livre de Julia Lerman sur Entity Framework, j'ai eu vraiment du mal avec le code en premier. Au cours de mes nombreuses années dans la création d'applications, j'ai emprunté de nombreux chemins, à la fois forcés par le processus et par choix, et j'ai constaté que j'avais beaucoup plus de succès lors de l'adoption d'une vue centrée sur les données lors de la création d'une application.

Je parle ici des applications métier ... c'est quand vous avez un problème ou un processus métier qui a besoin d'une solution logicielle derrière. Vous avez des données qui doivent être gérées d'une manière ou d'une autre. Il vaut mieux connaître vos données et comment elles se rapportent à elles-mêmes et comment elles sont utilisées au sein de l'entreprise. Par conséquent, vous modélisez ces données, puis créez une application / solution autour d'elle. D'après mon expérience, si vous commencez à créer l'application avec les données après coup, quelque chose finit par être laissé de côté, puis vous avez un refactoring (dans de nombreux cas - refactoring MAJEUR).

Les petites applications peuvent être une exception, mais je continuerai à utiliser mon approche centrée sur les données.

Je ne vois pas pourquoi CodeFirst ne peut pas être utilisé dans les grands projets d'entreprise. Je dirai que j'utilise EF CodeFirst dans plusieurs projets, un où la base de données est générée par mon modèle EF CodeFirst et le second où EF CodeFirst est mappé à une base de données existante.

D'après mon expérience, l'efficacité de CF dans un grand projet dépend fortement de l'abstraction de votre couche de données de votre couche métier.

Par exemple, dans l'un de mes projets, la couche métier appelle directement la base de données via linq. J'utilise Linq pour résumer ma couche de base de données et utiliser CodeFirst pour mapper mes POCO dans le schéma de base de données. Dans ce cas, CodeFirst simplifie considérablement le maintien des différences entre les conventions de base de données (noms de relation et de table) et mes noms de classe C #, et je peux apporter des modifications à la base de données sans avoir à affecter fortement la façon dont ma couche métier interagit avec la base de données.

Cependant, dans un autre projet, j'ai résumé l'accès à la base de données dans un modèle de référentiel non générique, et les méthodes Get * de mon référentiel sont uniquement responsables de l'exécution des requêtes sur la base de données, et elles retournent des objets réels (pas des IQueryable<T>s). Dans ce cas, les méthodes de référentiel convertissent les entités DB en entités POCO et dans ce cas, CodeFirst ne vous offre pas autant d'avantages que les POCO CodeFirst sont de courte durée et sont rapidement convertis en classes C # de la couche métier.

En fin de compte, cela dépend vraiment de la façon dont l'équipe est structurée et de la façon dont l'équipe (ou les personnes âgées) est à l'aise avec les ingénieurs non-DBA modifiant les schémas de base de données, et de la façon dont les changements de schéma vont affecter votre structure de code. Avec CodeFirst mappé à une base de données existante, il est trivial pour moi de remapper une propriété à un nouveau nom de colonne sans avoir à renommer globalement ce nom de propriété, ce qui est particulièrement un facteur lorsque vous parlez d'un nom qui a plus de sens pour un champ de base de données plutôt qu'une propriété C #. Il est également trivial pour moi d'ajouter le support de code pour les nouveaux champs de base de données sans avoir à remodeler complètement mes entités C # (l'une des raisons pour lesquelles j'ai laissé Linq-to-sql à EF CodeFirst à partir d'une base de données existante).

Code First ne convient pas aux applications à grande échelle. Le délai de développement des applications à grande échelle est très énorme.

En règle générale, le cycle de vie de votre application d'entreprise est comme,

1. La version 1 est en production
2. La version 2 est en beta
3. La version 3 est en développement actif
4. La version 4 est en cours de planification.

Et il existe d'autres ponts de communication inter-applications, certaines tâches planifiées, une intégration tierce partie, des services Web pour différents appareils communicants tels que le mobile, etc.

Finalement, Code First utilise ObjectContext d'Entity Model, les anciens EF générant EDMX et utilisant ObjectContext avec EntityObject étaient vraiment suffisants pour tout. Vous pouvez facilement personnaliser le modèle de texte pour générer du code. La méthode Détecter les changements est plus lente avec l'implémentation d'ObjectContext, mais au lieu de générer un proxy, l'équipe EF aurait pu facilement améliorer la vitesse de détection des changements au lieu de réinventer le code en premier.

Migration automatisée

La migration automatisée semble bonne en théorie, mais impossible en pratique une fois que vous êtes en ligne. C'est seulement bon pour le prototypage, en développant quelques démos rapides.

Code First Migration n'est pas du tout approprié dans un tel système. Les versions 1 et 2 parlent probablement à la même base de données. La version 3 et la version 4 sont généralement intermédiaires et ont une base de données différente.

Base de données d'abord

Database First est une approche pratique, il est facile de comparer et de visualiser et de maintenir des scripts SQL. Les DBA peuvent fonctionner facilement.

Modèles de texte

Nous avons créé nos propres modèles de texte pour interroger et créer EDMX et ObjectContext avec peu d'implémentation personnalisée qui résout les problèmes de performances. Il existe plusieurs applications avec plusieurs versions communiquant sans problème avec la même base de données.

Pour moi, faire un clic droit sur le fichier .tt et cliquer sur "Exécuter l'outil personnalisé" est de loin l'étape la plus rapide et la plus simple, puis écrire des classes, configurer et créer un modèle.

Habituellement, pour les grands projets, la base de données a déjà été créée. Soit parce qu'il s'agit d'une base de données héritée, soit créée par un dba compétent pour les performances. Le seul avantage de CodeFirst est que vous ne souhaitez pas utiliser les entités EF mais plutôt les POCO.

Il me semble que "Code First" est destiné à utiliser EF avec plus "agile" (ne harpe pas trop sur ce terme, je ne parle pas nécessairement de la méthodologie) et des applications greenfield, où vous n'avez pas de modèle de données existant ou données existantes; le type d'application que vous pouvez également utiliser Django, ou un framework PHP, ou Rails pour suivre les directives de ces frameworks qui impliquent normalement la création du modèle de données dans le code, au lieu de construire une application autour d'un modèle de données qui est le traditionnel Manière Microsoft de gérer les choses.

Donc, pour répondre à la question, je dirais non; si vous avez déjà des données existantes et que vous créez une application pour les gérer, Code First n'a pas autant de sens. Cependant, et je n'ai pas beaucoup utilisé EF du tout, et encore moins Code First EF, il semble que ce soit une approche plus lâche du code, ce qui est toujours bénéfique. En supposant que vous pouvez utiliser Code First et ensuite pointer la classe vers un modèle de données existant (au lieu d'être forcée de générer le modèle), l'approche Code First pourrait toujours aider à écrire du code correctement résumé et testable sans toutes les «cruautés» habituelles d'utilisation. Entity Framework (c'est-à-dire les métaclasses générées).

Je dirais que dans les très gros projets, le code en premier n'a pas de sens.

En fait, lorsque le projet devient vraiment important, vous avez souvent une séparation stricte des préoccupations. Vous ne pouvez pas avoir la même personne qui écrit du code C #, qui fait la conception de bases de données, l'écriture HTML / CSS et la conception visuelle dans Photoshop. Au lieu de cela, la conception de la base de données est effectuée par un administrateur de base de données (ou au moins par une personne dédiée qui connaît son travail).

Étant donné que la base de données est conçue par une personne familiarisée avec la base de données, le SQL et les outils d'administration et de conception de base de données, il serait étrange de voir cette personne utiliser Entity Framework.

De plus, je ne sais pas si Entity Framework est suffisamment puissant pour concevoir correctement la base de données. Et les index? Contraintes? Vues?

Le code d'abord est viable même pour les grands systèmes: il suffit d'examiner le modèle après sa création et de le remapper à l'aide de l'API fluide jusqu'à ce que vous atteigniez un modèle de base de données que vous aimez.