Cartographie d'un DTO partiellement peuplé à un objet de domaine

J'utilise DTO entre mes couches d'affaires et de présentation et ont un code de mappage dans le service qui convertit DTO < -> objet de domaine. Je permets actuellement le PL pour remplir partiellement un DTO et l'envoyer à un service de mise à jour, qui met à jour uniquement les propriétés modifiées sur la DO associée.Cartographie d'un DTO partiellement peuplé à un objet de domaine

Quelle est la façon habituelle de traiter les types non nullables (valeur) dans DTO partiellement peuplées? Pour les types NULL, je vérifie simplement si la valeur DTO est nulle et, si ce n'est pas le cas, mets la valeur correspondante sur le DO. Mais les non-nullables contiendront toujours une valeur, qui peut ou non avoir été définie par le PL.

je pouvais:

utiliser des chaînes de forme libre dans le DTO pour les propriétés fictivement typée valeur et convertir en/du type de valeur
effectuer l'appel PL une méthode de service pour mettre à jour la valeur propriétés plutôt que de les passer par le DTO
vigueur le PL d'envoyer toujours un DTO entièrement rempli au service de mise à jour

Aucun de ceux qui semble idéal: est-il une option que je suis absent? Ou est-ce que j'aborde ce problème sous le mauvais angle?

Si elle est pertinente, j'utilise C# 4, WCF et ASP.NET MVC

Source

2010-09-01 Ben Hughes

Pourriez-vous donner plus d'informations sur les types de valeurs non annulable que vous avez mentionnés? Connaissez-vous Nullable Types qui peut être utilisé dans votre DTO?

Source

2010-09-01 05:59:50 orka

Par types non-nulles, je veux dire DateTime, Enums etc. Si j'utilise des types Nullable (par exemple DateTime?) Dans le DTO, est-ce un concept générique (non-C# spécifique) qui fonctionnera? Bien que j'utilise .NET aux deux extrémités, je souhaite que le service soit indépendant du client. –

types nullables travailleront à travers le fil même avec d'autres plates-formes. Bien qu'il y ait une certaine dégradation des performances (à cause des classes wrapper pour les types Nullable qui devraient être créés pour d'autres plates-formes telles que Java), cela devrait fonctionner normalement. Une solution alternative peut être une propriété supplémentaire qui indique l'état nul de la propriété associée. Par exemple; En plus de Montant, vous pouvez ajouter une propriété AmountIsNull pour vérifier si elle est nulle. – orka

Une façon est de transmettre la liste des propriétés modifiées au service de mise à jour. Cela peut être aussi simple que d'avoir un entier où chaque bit indique une propriété OU un tableau d'indices ou de noms de propriété, etc. Vous pouvez également effectuer le suivi automatique de votre DTO dans le sens où chaque DTO conservera quelles propriétés ont été modifiées. Je ne préfère généralement pas ces mises à jour partielles - si elles sont autorisées alors IMO, il serait logique de créer un DTO composite (diviser les propriétés en groupe de propriétés appartenant à des objets enfants) où le client a la possibilité de mettre à jour au groupe niveau (toutes les propriétés du groupe doivent être renseignées). Si le contrôle de la mise à jour est nécessaire à chaque niveau de la propriété puis il plus judicieux d'utiliser PropertyBag (dictionnaire de nom/index - paire de valeurs) de type DTO.

Source

2010-09-01 07:16:33 VinayC

Cartographie d'un DTO partiellement peuplé à un objet de domaine

Répondre

Questions connexes