EF4 Code-premier vs modèle-d'abord en ce qui concerne la validation du modèle

Premier code d'abord est dans CTP et ne dispose donc pas d'une licence Go-Live. S'il s'agit d'un projet à livrer dans les prochains mois, la décision est la décision d'abord.

Ayant dit que, les premières classes de codes utilisant des donnéesAnnotations sont plus propres que le modèle de premier modèle avec des classes de copains, mais la chose la plus importante de mon expérience est une intention explicite. Tant que votre conception est claire et que, surtout, une approche convient parfaitement.

Pour un petit projet (c'est-à-dire un homme comme vous l'avez dit), je dirais que vous allez probablement être plus productif avec le modèle d'abord et concevoir via un EDMX. Cela se sentira également plus confortable pour vous venant d'une première expérience de schéma. Il y a cependant un certain nombre de cerceaux que vous aurez besoin de passer pour que les classes de POCO fonctionnent bien, telles que l'installation du modèle POCO T4, puis modifier le modèle T4 créé dans votre projet pour tirer le POCO dans un assemblage séparé. Vous ne les voulez pas dans l'assemblée DAL qui est où ils vont commencer. Vous êtes ensuite laissé avec la décision de la manière dont vous êtes à l'aise avec des classes partielles pour la mise en œuvre de dataannotations; Pour des raisons pour des raisons, je ne suis pas d'accord avec beaucoup de gens les voient comme une design médiocre.

Dans un projet MVC, vous appuierez sur le problème sec d'omniprésents à l'aide de dataannotations avec une approche lorsque vous décidez d'utiliser des images de vue. À ce stade, vous réaliserez soudainement que l'annotation étendue de votre modèle de validation n'est utile que si vous êtes heureux d'envoyer ces classes directement à la vue. Si vous décidez de conserver les vues Léger et d'utiliser des images de vue, vous devez répéter les données de données sur la vue sur la vue, sinon vous êtes laissé avec des erreurs de validation au niveau du modèle, mais aucun moyen de l'obtenir dans la modélisation autre que l'ajout manuel. Ni le code premier ou modèle ne résolvent-il pas encore ce problème, vous devez donc concevoir en conséquence. Nous sommes personnellement allés avec un mélange et acceptons un niveau de sécheresse.

Quel type de validation recherchez-vous? Voulez-vous injecter des règles de validation d'entrée utilisateur dans des entités ou souhaitez-vous une couche de validation uniquement sur les opérations de la base de données?

Il y a beaucoup de discussions puristes que les entités ne doivent pas contenir d'attributs de validation, car vous ne les utiliserez jamais dans des vues - vous utiliserez des classes de modèle de type spécial et des paramètres de validation seront directement sur les propriétés de ces classes. Pour les projets moyens et grands, je suis d'accord. Pour de simples projets de gestion de données, qui sont plus comme des formulaires sur les données (juste des opérations de crud), je suis en désaccord parce que c'est une complexité supplémentaire que vous n'avez pas besoin.

Le code EF introduit d'abord les annotations de données utilisées comme validation de la couche DB (BTW. La validation de la couche de données peut être complètement différente de la validation de l'UI). J'ai essayé exactement la même approche avec le fichier EDMX avant que cette fonctionnalité soit introduite en premier. Vous peut définir les attributs de validation pour les classes générées par EF T4 Poco Modèle également. Un problème avec ma mise en œuvre de la validation (basée sur la réflexion) était que si j'avais effectué beaucoup de mises à jour et que cela a été extrêmement lent - je ne le comparais pas au code d'abord.

EDIT:

basé sur Annonce actuelle dans l'équipe Ado.net Blog Next EF (RC prévu à la fin mars) prendra en charge la validation dans les trois approches - Code Premier, la base de données en premier, Modèle en premier. Je ne sais toujours pas si cela signifie la validation de la validation dans les implémentations basées sur DBContext et ObjectContext.