我们目前有一个WCF服务，它已经为枚举设置了自己的DataContracts . 然后，我们在DataContract枚举和业务层中可用的公共枚举之间有一个映射层 . 同样的事情发生在客户端 - 客户端枚举和数据协定枚举之间的映射层
我们今天早上一直在讲述通过WCF服务公开我们的常见枚举然后到客户端，我们不知道这是否是最佳实践 . 因此，这个问题归结为是否允许交叉关注来自我们后端，通过服务和客户端系统的枚举或者我们是否应继续将我们的数据 Contract 与基本代码库分开是一件好事 . 我们正在努力为我们的服务实现SOA的最佳实践 .
人们对此有何看法？
3 回答
如果您想要最佳实践，那么当前的设置听起来非常合理 - 您可以使用单独的DTO层轻松管理边界处的版本控制和其他验证/映射 .
如果你在边界上有一个完整的DTO图层（而不是在边界上暴露你的常规/事务域实体），这会很有用，听起来你可能会这样 .
缺点是增加维护，但它使它们非常灵活，并避免任何意外问题 . 例如，它通常不适用于WCF，但常规Web服务的典型错误是添加非默认构造函数（从而删除编译器生成的默认构造函数） . 哎呀！没有更多的网络服务 . 有一个类似的主题是由无辜的变化引起的错误，可以通过分离出DTO来避免 .
我会在服务级别使用单独的数据协定枚举，从版本兼容性POV映射到BL枚举 . 即使来自BL的枚举值发生变化，这将允许将来保持相同的服务枚举值和解释 . 例如，您可以在服务和业务级别以4-5个相同的值（0,1,2,3,4）开始 . 将来，您决定将业务枚举修改为基于标志的解释 - 因此，具有单独的服务枚举将允许将这些值映射到新的业务枚举值（希望在该级别可以获得相同的解释） - 对于考试3现在可以在业务枚举中映射到8 .
我目前处于相同的情况 . 一种解决方案是使用另一个可以调用ServiceManager的薄层 . 此层中的方法接受数据协定枚举，然后在调用BL方法时将数据协定枚举类型转换为BL枚举类型 .
但我已经决定我的解决方案是删除数据 Contract 枚举，只使用字符串常量 .
如果您有更好的解决方案，请分享 .