Conception EF4 DAL et ObjectContext: Argument avec un collègue

Question

Je travaille avec un développeur senior qui est un gourou .NET architecte. Nous avons eu de nombreux arguments constructifs au cours des six derniers mois et, en général, je concède une défaite dans la plupart de nos discussions. J'ai appris des piles de travailler avec lui. Cependant, il y a un problème de conception avec lequel nous sommes actuellement en désaccord, et j'aimerais avoir quelques opinions/suggestions parce qu'il n'a pas réussi à me convaincre de sa position, et je vais m'en tenir à mes armes jusqu'à ce que quelqu'un puisse me prouver je me trompe. Nous utilisons Entity Framework 4.0 et nous utilisons les deux entités PERFORMANCE AND Self Tracked dans les différents modèles. Nous avons commencé à utiliser des entités auto-suivies pour suivre les modifications apportées aux graphiques d'entités que nous avons sérialisés/désérialisés sur le fil WCF à notre application Silverlight. Cela fonctionne fantastique. Nous avons également commencé à utiliser des entités auto-suivies pour les modèles que nous ne prenons pas à travers la WCF, mais beaucoup restent en tant qu'entités/modèles persistants. Mon collègue est d'avis que Entity Frameworks ObjectContext doit être conservé le plus rapidement possible. Il insiste sur le fait que cela ne devrait durer que le temps nécessaire pour faire une requête et le temps nécessaire pour persister quelque chose. Tout travail d'entreprise effectué avec des entités doit être détaché. Pour chaque modèle d'entité que nous avons, nous avons une classe de requête et une classe persistante qui sont à la fois IDisposable et ont le ObjectContext à la portée de l'instance et ont la logique de requête/persistance dans les méthodes. Nous utilisons ces classes de requête/persistance dans notre logique métier plutôt que d'utiliser ObjectContext directement dans la logique métier. Lorsque ces instances de classe sont construites, ObjectContext est mis en place et, lorsque Disposé, ObjectContext Disposed l'est également. Ces classes sont comme des wrappers autour de nos opérations LINQ séparant EF de la logique métier et facilitant la réutilisation des requêtes LINQ.

maintenant d'abord considérer non autonomes entités chenillés:

Je comprends pourquoi il veut que ce soit et le désir de ne pas avoir une ObjectContext longue course, mais mon problème est qu'il veut toujours même logique métier trivial à être détaché de le ObjectContext et le fait que nous ayons un contexte de requête et de persistance distinct sous notre conception signifie qu'il n'y a pas de suivi d'état ObjectContext des Entités utilisées dans notre logique métier. Pour les entités non auto-suivies, cela signifie que si nous modifions les entités dans notre logique métier, nous devons également définir manuellement l'état modifié des entités avant de persister. C'est une douleur RÉELLE quand persistent les graphiques complexes avec de multiples changements. Aussi je doute que nous puissions le faire manuellement ainsi que EF le fait automatiquement. Pour nos entités auto-suivies, cette situation est la même, car le suivi n'est activé que lorsque les graphiques sont désérialisés. Ainsi, lorsque vous travaillez dans un service où la requête a été effectuée, détachée du contexte, il n'y a toujours pas de suivi. Entités auto-suivies.

Ma question est la suivante: quelle est la meilleure pratique pour l'utilisation du framework Entity et comment doit-on concevoir un DAL Entity Framework? Combien de temps le ObjectContext doit-il être autour? La logique métier doit-elle toujours être détachée de ObjectContext? Si oui, comment faisons-nous le suivi d'état lorsque vous travaillez détaché de ObjectContext? Une option à laquelle je pense consiste à convertir TOUTES nos entités en entités auto-suivies et à utiliser un code de traversée de graphes pour parcourir les graphiques interrogés et activer le suivi pour toutes les entités du graphique afin que le suivi automatique soit activé même lorsque le service fonctionne (imitant fondamentalement ce qui se passe lorsque le graphe des entités auto-suivies est désérialisé) ...

Je ne propose pas de garder l'ObjectContext pendant de longues périodes, mais de travailler de manière détachée entre la requête et la persistance et de perdre le avantages de l'état ObjectContext me semble stupide ... nous perdons l'un des grands avantages de EntityFramework ...

Désolé pour un long message ... toute aide appréciée.

Answer 1

Microsoft recommande que le ObjectContext soit de courte durée, et mon expérience m'a amené à croire que la durée de vie d'un ObjectContext devrait idéalement correspondre à la durée d'une opération web-request/user.

J'ai fait l'erreur d'essayer d'utiliser un ObjectContext global et de longue durée dans une application de bureau, et c'était un désastre total. Si vous souhaitez implémenter des éléments tels que la mise en cache, sous/redéfinir les sémantiques, etc., vous devez envisager une conception utilisant des classes ViewModel distinctes des entités de données sous-jacentes. Utilisez l'EntityFramework pour vous aider à construire votre graphe d'objet Modèle, puis créez le ViewModel à partir de celui-ci. Lorsque vous souhaitez enregistrer les modifications, autorisez votre Référentiel ViewModel à se reconnecter aux entités sous-jacentes, à modifier leurs propriétés et à enregistrer les modifications. Ceci permet une conception plus "cachable", flexible, indépendante de l'ORM, facile à tester. Pour ce qui est du suivi des modifications, essayez de ne pas le considérer comme un mécanisme bon marché «fait par l'utilisateur» pour l'interface utilisateur, mais plutôt comme un mécanisme coûteux pour suivre les entités récemment créées qui doivent être considérées. lors de l'enregistrement des modifications