WCF Data Contracts and Sharing of Enums

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 pr开发者_如何学Pythonactice 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.

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.

I am currently in the same situation. One solution is to have another thin layer you can call ServiceManager. The methods in this layer accepts the data contract enums then this converts the data contract enum type to a BL enum type upon calling the BL methods.

But I have decided that my solution is to remove the data contract enums and just use string constants.

Please share if you have a better solution.