Structure de datacontract complexe : demande pour bon usage

Bonjour à tous,

désolé pour le titre pas vraiment explicite mais trop compliqué à résumé...
Je suis face à une problématique d'optimisation au niveau d'un projet N-tiers.

J'ai une appli silverlight, avec une reference vers mon webservice WSDL.
Ce webservice fait appel à une couche data EDM.
Lorsque j'ai besoin de rappatrier des données, silverlight fait appel à ce webservice et je me retrouve avec une liste d'objets plus ou moins complexes.

Imaginons le cas suivant :
un datacontract CtA possèdant des propriétés dont une étant de type datacontract CtB et une autre de type datacontract List<CtC>.

Aujourd'hui mes datacontracts et mes entity de EDM sont totalement détachés. Lorsque j'enregistre un Datacontract CtA, je dois reconstruire mon entity EntA à partir des property du datacontract. Et vice versa : lorsque je récupère un contract CtA, je dois le construire à partir de mon entity EntA.

Deux problématique là dedans :
1) Je dois transferer mes property de l'entité vers le contract et ce pour chaque objet envoyé ce qui fait énormément de code.
2) Vous pourriez me dire : "bah au lieu d'envoyer le contract, envoie l'entity directement" ce à quoi je répondrai : impossible car nous aimerions avoir une signature propre (EDM générant des objets dont les propriétés correspondent aux nom des champs, pas forcement explicites pour ceux qui les utilisent de l'exterieur - car le webservice va etre utilisable par d'autres sociétés) et qu'en plus nous aimerions conserver la maitrise du truc.
3) Si je ne transmet pas l'entity dans le contract, il y a une bonne complexité pour pouvoir gérer les relations entre les objets. Si par exemple, j'envoie mon contract CtA au client, qu'il supprime un élément de la liste de CtC et qu'il retourne le tout au webservice, je dois me palucher manuellement la gestion d'intégrité de liste.
4) En envoyant les entity, j'ai un gros avantage, les objets redondants ont la même référence d'objet, et de ce fait les données ne sont pas reserialisées, mais un pointeur dans le flux XML apparait ce qui economise en poids de flux.

Par rapport à ces contraintes, j'ai essayé de créer un datacontract Wrapper. En gros, j'embarque l'entity comme datamember, puis je créé toutes les property qui m'interessent. Ces property ne font qu'attaquer l'entity via des this.Entity.Name = value et return this.Entity.Name
La problématique avec cette solution presque parfaite est que la sérialisation se fait deux fois :
une fois on serialise toutes les données de l'entity
une fois on serialise chaque donnée de chaque property Wrapper.

J'aurais aimé virer la deuxieme ligne mais je ne trouve pas de solution qui permette de conserver les property wrapper coté client, sans pour autant les serialiser/deserialiser.

Bref, ma question est la suivante : dans un projet de ce genre, comment mettez vous en relation la couche data et la couche webservice ? faites vous du remplissage de contract ? Envoyez vous directement l'objet sortant de la couche données ?

Merci d'avance pour vos avis :)