Utilisation des objets d'entités ADO.NET et des services Web basés sur les fonctions de savon

Question

Je construis un service Web ASP.NET traditionnel - le style construit à l'aide d'asmx. C'est un service assez simple. J'ai commencé à utiliser le nouvel Ado.NET Entity Framework pour ma couche de persistance, et je rencontre quelques problèmes:

1) Je n'aime pas le WSDL qui est généré automatiquement - les types complexes étaient définis comme si:

<s:complexType name="TestObject"> 
     <s:complexContent mixed="false"> 
     <s:extension base="tns:EntityObject"> ... 

alors, je construit mon propre WSDL et utilisé l'outil wsdl.exe pour créer une définition de service, qui comprend une nouvelle définition de type, maintenant le WSDL ressemble, que je sens une plus croix -plateforme design:

<xsd:complexType name="TestObject"> 
    <xsd:sequence> 
    <xsd:element minOccurs="0" name="created" type="xsd:dateTime"/> ... 

J'ai maintenant l'ASPX générant une belle Fichier WSDL. Mais maintenant je ne suis pas sûr d'où je devrais prendre ceci. J'ai deux types de fondamentalement le même type pour TestObject: 1) qui est utilisé pour la persistance d'entité avec le ADO.NET Entity Framework 2) et un qui est utilisé pour définir des données à travers le fil.

Je voudrais savoir comment les combiner en un. Je suis un peu nerveux à propos de la modification du fichier .cs qui a été généré automatiquement par le framework Ado.NEt Entity, car il semble qu'il pourrait être écrasé.

Quelqu'un avec beaucoup d'expérience avec l'expérience de l'entité Ado.Net pense qu'il vaut la peine d'utiliser? Bien que j'aime l'idée de la rapidité avec laquelle j'ai été capable de créer de la persistance dans ma couche de données, je dois définir de façon très personnalisée comment l'objet entité est transféré sur le réseau, donc j'ai besoin de modifier les attributs associés Propriétés. De même, dans mon implémentation de service, je ne veux pas vraiment convertir d'EntityFramework.TestObject en WSDLDefenition.TestObject.

Merci pour toute contribution.

Answer 1

Vous êtes confronté au type de mur auquel nous sommes confrontés lorsque nous essayons d'utiliser Entity Framework dans une architecture de style SOA.

La version 1.0 d'Entity Framework ne fonctionne pas très bien dans le scénario que vous avez décrit, car vous finissez dans un monde de mal à essayer de gérer les contextes d'objets (et probablement devoir les mettre en cache).

Je recommande une lecture approfondie de ce qui suit (1) article posté par l'équipe EF sur l'avenir de l'Entity Framework. Cela a également pour effet de saisir et de discuter de certaines lacunes actuelles. En bref, je ne suis pas sûr que l'Entity Framework soit tout à fait la solution que vous voulez actuellement, car il n'y a pas de solution «propre» pour gérer les entités EF à travers le réseau (ou les limites de service extérieures) à ce stade.

D'autres peuvent différer ... mendier

PS Vous avez raison d'être méfiant de la main modifier le code généré - des mises à jour du modèle de données remplacera toutes les modifications (même si vous pouvez l'étendre comme ils sont dans une classe partielle). Pas utile si vous voulez ajouter des attributs aux propriétés si.

(a) http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx

Answer 2

Merci. C'est ce que je soupçonnais, mais je ne voulais pas passer une journée entière à faire des recherches.Ce que je vais faire pour l'instant est de garder mes objets séparés, de cette façon je peux garder le WSDL propre, puis dans une couche d'accès aux données, je vais convertir entre les objets sur le réseau et l'entité ADO.NET cadre.

Probablement pas l'approche la plus saine, mais cela va me servir pour la démo.

Merci pour le lien vers l'article, je pense que le concept clé qui me manquait était l'ignorance persistante. J'ai travaillé sur les services Web Java où vous pouvez définir POJO (Plain vieux objets Java) et les transférer sur le fil facilement, ainsi que de persister à la source de données ...

... et je vois maintenant pourquoi vous suggérez WCF, en raison de son soutien à l'ignorance persistante.