The problem is familiar - when marshalling user defined / domain types through service boundaries, do we simply annotate rich domain objects with [DataContract]
attributes (thereby polluting the domain with ServiceModel constructs), or do we implement some sort of DTO process (creating extra work for arguably little benefi开发者_Python百科t)?
- How are people resolving this conflict? Are there other approaches that have fewer downsides?
- If you're using the DTO approach, how do you go about implementing the transfer of property values from domain object to DTO?
Thanks
You have mostly answered your questions. If you want very clear design use DTO. If you don't want to add additional layer of complexity either mark classes with DataContract
/ DataMember
attributes or use defalut serialization (only .NET3.5 and newer) which takes all public properties (with getter and setter) + you can remove some properties from serialization by using IgnoreDataMember
attribute. To map domain objects to DTOs and DTOs to domain objects you can use AutoMapper.
If you use DTO (my suggestion), you can transfer information from DTOs to entities and vice versa using the assembler pattern. You can do it manually or you can use tools. AutoMapper is a good suggestion.
This may be obvious, but I want to add to what Ladislav has said. Like he mentions, you can use POCO types, but you also have the flexibility to go beyond and use IXmlSerializable, ISerializable, Serializable, and more; these other serialization moels do not have the flexibility of being used with IgnoreDataMember.
See this blog post for more information. It also details how DataContractSerializer would prioritize two conflicting programming models on the same type.
精彩评论