Cadre d'entité dans une architecture en couches?

Question

Faire des expériences autour de WCF et Entity Framework. Un couple de questions.

Option 1:

Je comprends que les classes cadres d'une entité peut être sérialisés sur WCF directement, avec sp1 partir. Cependant, j'aimerais savoir comment des scénarios tels que le chargement différé, le chargement passionné, la gestion de contexte, etc. sont traités, s'ils sont traités?

Option 2:

Une autre alternative pourrait être d'utiliser EFPocoAdapter, d'avoir une enveloppe POCO plaine au-dessus du cadre de l'entité, au lieu d'exposer les classes cadres d'entités directement. http://code.msdn.microsoft.com/EFPocoAdapter. Est-ce que quelqu'un a utilisé cela? Des pensées dans cette direction?

Autres pensées:

À propos des services de données ADO.NET - Si je comprends bien les services de données ADO.NET ne peuvent pas être configurées sur Remoting (NetTcp de liaison)? Il prend en charge uniquement l'accès basé sur http. Nous savons tous que la sérialisation binaire est plus lente.

Des pointeurs ou d'autres options?

Answer 1

J'ai creusé un peu à ce sujet, et voici mes conclusions à ce sujet.

ADO.NET Data Services:

Vous pouvez utiliser les services de données ADO.NET (vous avez besoin SP1) pour exposer votre cadre de l'entité sur le fil, avec presque le code zéro. Mais si je comprends bien, la seule limitation est, la transaction est sur HTTP. Cela signifie qu'il y a une petite surcharge en termes de sérialisation (nous savons tous que la sérialisation binaire est plus rapide), mais l'avantage est la rapidité de mise en œuvre de nos services.

j'ai reçu un mot officieux de John [http://twitter.com/John_Papa] sur ce point - «. Certainement plus d'options avec WCF Plus de travail dans la plupart des cas trop Astoria expose les entités facilement diffs Perf sont négligeables dans la plupart des cas. »

Les avantages - Vous n'avez vraiment besoin d'écrire aucun service - Vous pouvez simplement connecter la logique de validation et de sécurité autour des services de données et du framework d'entité et nous avons terminé. Idéal si vous consommez des services centrés sur des données dans des scénarios http, par exemple, avec un client Silverlight ou un front-end winform/wpf sur http.

Révéler Entity Framework sur WCF:

Avec SP1, il y a beaucoup de soutien pour l'emploi cadre de l'entité dans les architectures en couches. Cela inclut le support pour le chargement et la gestion du contexte.Bien sûr, dans ce cas, nous devons écrire les services (et la logique derrière nos méthodes). Ou si nous avons le modèle de cadre d'entité totalement aligné avec la base de données, nous pourrions générer la plupart des services, ce qui inclut les méthodes dont nous avons besoin.

recommandez-vous lire ce http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

Une autre alternative pourrait être d'utiliser EFPocoAdapter, d'avoir une enveloppe POCO plaine au-dessus du cadre d'entité pour dtos, au lieu d'exposer les classes cadres d'entités directement. À l'heure actuelle, il s'agit d'un projet de boussole pour la prochaine version de Entity Framework http://code.msdn.microsoft.com/EFPocoAdapter.

Answer 2

C'est une très mauvaise idée d'exposer les classes EF sur WCF. Microsoft a fait quelques erreurs sérieuses qui empêchent cela d'être un scénario utile. Ils ont exposé les entités en tant que contracts de données, mais aussi les classes de base de l'entité, et pour les liens en arrière, exposent deux copies du lien. D'autre part, il semble que ADO.NET Data Services a de la magie qui permet à quelque chose de proche de fonctionner. Lisez l'article SilverLight dans MSDN Magazine de ce mois-ci pour un exemple, du côté client, de l'utilisation de ADO.NET Data Services.

Answer 3

Pour ne pas évoquer un ancien post mais ... J'ai trouvé cette annonce quand on a eu le même problème. Nous avons des services WCF et un modèle de domaine Entity Framwork. Au final, j'ai fini par créer un T4 basé sur le travail de Danny Simmons qui prend l'EDMX et construit des classes de messages POCO avec des méthodes d'extension qui mappent entity.ToMessage() et message.ToEntity (objectcontext).

Cela a semblé être la meilleure approche intermédiaire jusqu'à .NET 4.0 car il ne nécessite aucune dépendance de projet externe supplémentaire ou des arceaux pour passer à travers comme les autres méthodes que j'ai trouvées (basées sur PostSharp). Si quelqu'un d'autre pense que cette approche serait utile faites le moi savoir et je posterai le lien vers le fichier TT sur notre site googlecode.