WCF Data Contracts and Sharing of Enums

Question

We currently have a WCF service that has been setup with its own DataContracts for the enumerations. We then have a mapping layer between the DataContract Enums and the Common Enums available in our business layer. The same thing happens on the client end - a mapping layer between the client Enum and the Data contract Enum

We have been speaking this morning about exposing our common enums through the WCF service and then onto the client and we do not know if this is a best practice or not. This Question therefore comes down to whether it is a good thing to allow cross cutting of concerns for enumerations that stems from our backend, through a service and into a client system or if we should continue to keep our data contracts separate from our base code library. we are trying to achieve a best practice SOA for our service.

what are peoples thoughts on this?

Answer 1

I would go for having separate data contract enum at service level that maps to BL enum from version compatibility POV. This will allow in future to keep same service enum values and interpretation even if enum values from BL changes. For example, you may start with 4-5 same values (of 0, 1, 2, 3, 4) at both service and business level. In future, you decided to modify business enum to a flag based interpretation - so having separate service enum will allow to map those values to new business enum values (hoping that same interpretation would be available at that level) - for examle 3 will now may get mapped to 8 in business enum.

Answer 2

If you want best-practice, the current setup sounds pretty reasonable - you can manage versioning and other validation/mappings at the boundary pretty easily with a separate DTO layer.

This applies doubly if you have an entire DTO layer on the boundary (rather than exposing your regular/transactional domain entities on the boundary), which it sounds like you might.

The downside is increased maintenance, but it makes them very flexible, and avoids any unexpected issues. For example, it doesn't apply to WCF usually, but a classic error with regular web-services is adding a non-default constructor (thus removing the compiler-generated default constructor). Oops! no more web-service. There is a similar theme of bugs caused by innocent-looking changes that can be avoided by separating out the DTOs.