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?
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.