Entity Framework avec les services RIA, Silverlight - compromis entre le découplage et le développement rapide

Question

J'ai récemment joué avec Entity Framework, WCF RIA Services et Silverlight 4. Je suis impressionné par la rapidité avec laquelle vous pouvez développer une application avec ces outils, et vous obtenez beaucoup "gratuitement", comme l'interface utilisateur Silverlight connaissant automatiquement certaines validations qui sont incluses en tant que DataAnnotations sur le modèle EF. Cependant, il semble que dans une grande application, il ne serait pas souhaitable d'avoir une dépendance sur EF poussée tout au long de l'application entière, y compris la logique métier et l'interface utilisateur. Je sais que vous pouvez utiliser POCO/IPOCO avec Entity Framework, et c'est certainement une option pour moi. Cependant, si vous suivez cette voie, vous perdez certaines choses «automagiques» telles que Silverlight qui peut montrer des validations de modèle sans travail supplémentaire.

Comment les gens gèrent-ils cela? Est-ce que vous abandonnez une partie de la puissance et mettez des interfaces entre les différentes couches afin de découpler les autres couches de EF? Ou abandonnez-vous le découplage pour permettre un développement plus rapide? Y at-il un moyen d'avoir mon gâteau et de le manger aussi que je ne vois pas?

Answer 1

Mon groupe est actuellement confronté à ce problème. Nous avons trouvé un compromis décent que tout le monde était content. Gardez à l'esprit que, avant que tout ne soit fini, les projets deviennent plus compliqués avec le temps et la maintenabilité est la clé. Vous souhaitez également augmenter la réutilisation du code autant que possible, le remplacement de votre interface utilisateur (ou tests unitaires) est donc un effort minimal. Compte tenu de tout cela, nous avons privilégié une couche de domaine bien définie au lieu de pousser l'EF jusqu'à l'interface utilisateur. Cela fait du modèle le cœur de l'application et ne nous oblige pas à nous conformer au schéma de notre base de données. Je sais qu'EF essaie d'abstraire cela avec son modèle conceptuel, mais nous avons continué à courir dans de petites pièges qui rendaient de plus en plus difficile de compter sur EF pour la pile complète. Par exemple, il n'y a vraiment pas un bon endroit pour mettre la logique métier avec EF. Nous ne voulions pas mettre cela dans Interceptors et nous ne voulions pas le mettre dans l'interface utilisateur. Bien sûr, il pourrait y avoir une solution astucieuse pour cela, mais nous n'apprécions pas la direction dans laquelle nous étions poussés.

Le compromis était d'utiliser EF mais de le conserver entre le magasin de données et le modèle de domaine. De cette façon, nous n'avons toujours pas besoin de programmer contre DataReaders, et nous pouvons tirer parti des avantages des entités d'auto-suivi dans le domaine. Nous exposons ensuite les services de base WCF (non RESTful) de notre domaine à nos interfaces utilisateur.

Pour nous, le travail de validation supplémentaire n'était pas vraiment une grosse affaire. Bien sûr, notre version initiale prend un peu plus de temps, mais le cycle de maintenance global ne prend pas beaucoup de temps car nous ne sommes pas en train de finaliser les complexités du framework.