views:

121

answers:

2

I'm using DTOs between my business and presentation layers and have some mapping code in the service that converts DTO <-> domain object. I'm currently allowing the PL to partially populate a DTO and send it to an Update service, which updates only the changed properties on the associated DO.

What's the usual way of dealing with non-nullable (value) types in partially populated DTOs? For nullable types I just check if the DTO value is null, and if not, set the corresponding value on the DO. But the non-nullables will always contain a value, which may or may not have been set by the PL.

I could:

  • use free-form strings in the DTO for the notionally value-typed properties and convert to/from the value type
  • make the PL call a service method to update the value properties rather than pass them via the DTO
  • force the PL to always send a fully populated DTO to the Update service

None of those seems ideal: is there an option I'm missing? Or am I approaching this problem from the wrong angle?

If it's relevant, I'm using C# 4, WCF and ASP.NET MVC

+1  A: 

Could you give more information about the non-nullable value types that you mentioned? Are you aware of Nullable Types that can be used in your DTO?

orka
By non-nullable types I mean DateTime, Enums etc. If I use nullable types (eg DateTime?) in the DTO, is that a generic (non-C#-specific) concept that will work across the wire? Although I'm using .NET on both ends, I want the service to be client agnostic.
Ben Hughes
Nullable types will work across the wire even with other platforms. Although some performance degradation (because of wrapper classes for nullable types which should be created for other platforms such as java) it should work normally. An alternative solution may be an extra property that indicates the null state of the related property. For example; in addition to Amount you may add an AmountIsNull property to check it whether null.
orka
A: 

One way is to pass the list of properties changed to the Update Service. This can be as simple as having an integer where each bit indicating some property OR array of property indices or names etc. You can also make your DTO's self tracking in a sense that each DTO will maintain what properties have been changed.

I typically does not prefer such partial updates - if these to be allowed then IMO, it would make sense to create a composite DTO (divide properties into group of properties owned by child objects) where client has ability to update at group level (i.e. all properties within group must be populated). If control to update is needed at each property level then it make more sense to use PropertyBag (dictionary of name/index - value pair) kind of DTO.

VinayC