Comment utiliser les propriétés en lecture seule définies dans des classes partielles (Entity Framework) sur ADO.Net Data Services

Question

J'ai des objets définis par Entity Framework auxquels j'ai ensuite ajouté des méthodes et des propriétés supplémentaires via des classes partielles. Je pense que je comprends la plupart des limitations liées à cela, mais je voulais confirmer quelque chose que je vois (ou, espérons-le, apprendre ce que je dois faire pour que cela fonctionne).

J'ai une classe partielle qui a ensuite une propriété en lecture seule qui utilise quelques éléments pour créer un champ calculé en lecture seule. Il était curieux de voir que la propriété en lecture seule ne revenait pas via ADO.Net Data Services comme je l'espérais / l'attendais. c’est-à-dire que je m'attendais à voir les propriétés du framework d’entité et la propriété définie dans le code via la classe partielle arriver via l’appel du service de données.

Est-ce le cas? Les classes partielles sont-elles complètement ignorées lorsque ADO.Net Data Services interroge des données? Si tel est le cas, quelle est la meilleure pratique pour obtenir une propriété de type en lecture seule sur une entité (car j'aimerais éviter que les mêmes classes partielles avec différents espaces de noms ne soient copiées et collées dans les bases de codes côté client et côté serveur).

Answer 1

Extrait d'un message sur les forums Microsoft: ( Voir l'article complet ici. )

  

"Je pense que vous demandez" Comment ajouter un   propriété en lecture seule à un existant   entité qui est exposée par l'EF   fournisseur " ;? En V1, il n'y a pas de bonne façon   pour faire ça. Pour EF, nous chargeons le   métadonnées en utilisant les api de métadonnées EF   et par conséquent nous ne faisons aucune réflexion.   D'où des propriétés supplémentaires que vous   aurait pu ajouter via une classe partielle   sera ignoré.

     

Astoria n'a pas encore de concept de   propriétés en lecture seule. Donc, si nous exposons   toute autre propriété qui ne fait pas partie   du modèle, nous ne savons pas comment   traiter avec eux dans les mises à jour. Nous ne   vouloir perdre des données silencieusement dans le   serveur également. "

Il semble donc que cette fonctionnalité ne puisse pas être exposée via ADO.Net Data Services.

Answer 2

Il existe deux problèmes distincts ici: le modèle de base (EF) et la couche WCF / mex. Vos propriétés supplémentaires ne feront pas partie du modèle edmx, mais je me demande si le problème n’est pas davantage lié à l’aspect WCF / mex.

Toutefois, même si cela a fonctionné, ADO.NET Data Services transfère des données et non de la logique . Donc, s’appuyer sur des propriétés calculées n’est pas une option sûre: le client ne disposera pas des formules, mais uniquement des valeurs originales.

Pour savoir de quoi il s'agit, essayez de créer une propriété en lecture / écriture (même si l'écriture n'a aucune utilité), et assurez-vous que la valeur a un attribut [DataMember], etc.

Answer 3

Je pense que le problème est que, avec la sérialisation XML, il ne sérialise que les propriétés avec les méthodes get et set. Sinon, il ne pourrait pas désérialiser. Ajoutez une méthode de jeu vide à votre propriété et voyez comment vous allez.

Rob