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