Nous avons une référence de service qui pointe vers un service WCF. Elle agit comme un proxy à notre couche modèle où notre logique d'accès aux données est gérée. Sous le capot, nous utilisons Linq2Sql comme ORM pour faciliter la communication de la base de données.Contrôle des propriétés sérialisées via une référence de service
Nous utilisons les classes générées comme couche d'accès aux données, mais ce qui est retourné est en fait des objets DTO bêtes qui ne sont rien de plus que des POCO. Je voudrais faire deux choses)
1) Contrôler ce qui est disponible sur le client à travers la référence du service en termes de types personnalisés et leurs propriétés associées. C'est pour réduire la taille des classes qui descendent.
2) Je sais que Linq2Sql décore réellement toutes les classes générées avec mais je ne veux pas que ces classes descendent par la référence de service. À l'heure actuelle, si nous utilisons la classe comme type de retour de paramètre d'entrée, elle est sérialisée. C'est bien, sauf que je voudrais limiter quelles propriétés sont disponibles
Pensées?
Pas difficile - documenté! :-) C'est pourquoi je préconise d'utiliser ** toujours ** explicitement [DataContract] et [DataMember] sur vos DTO. Faire cela est un peu plus de travail à l'avance, mais alors vous êtes explicite et clair sur ce qui est sérialisé (et ce qui est ignoré). Ce travail supplémentaire sera payant plus tard en mode maintenance - plusieurs fois! –
Je suis d'accord, je ne l'ai tout simplement pas réalisé, en fait venu pour répondre AS je devais aller à la documentation :) drôle comment cela fonctionne. Et comme l'a dit Hal, nos classes générées sont abstraites et ne sont jamais utilisées comme valeurs de retour. – xximjasonxx