c# - 在业务层中有 [DataContract] 标记的类是一个糟糕的设计吗？

Question

我需要使用一个代表发送到我的 REST WCF 服务的客户端请求的类。

但我也想将此请求传递给我在业务层中的方法。（目前它是 WCF 服务的一部分）

在业务层中有 [DataContract] 标记的类是一个糟糕的设计吗？

Answer 1

我发现这是一个有用的答案。基本上，您的 POCO 可以在DataContractSerializer不添加[DataContract]属性的情况下进行序列化。

https://stackoverflow.com/a/14185417/1099260

Answer 2

正如我在评论中所说：

如果您对此感觉不好，请引入由该类实现的接口并在您的业务层中使用它。请注意，DataContract 属性只是序列化引擎的标记。

Answer 3

如果另一种选择是将合同几乎复制到不同的“BL 类”，只是为了让您对不将 DataContracts 发送到某个层感觉更好 - 我会说不要 - 发送 DataContract。

此外，“请求”、“命令”和“数据传输对象”并不是严格意义上的“外观”对象（或模式）。您可以在 DAL API 中使用请求对象（我假设是分层架构），以简化方法签名并启用未来的重构，对吗？那么为什么不在所有层中使用相同的请求对象呢？

如果存在与实际 DataContract 属性有关的部署问题（我想不出任何问题），那就另当别论了。

Answer 4

如果将来您需要 REST WCF 客户端请求服务的不同接口并且您无法控制消费客户端，那么如果您的 BL 严重依赖 WCF 合同类，您可能会遇到问题。您可能很难在不破坏 BL 的情况下修改服务接口，或者在不破坏与客户的接口的情况下修改 BL。

如果以上都不适用于你，我会说继续@Rahal 在他的评论中所说的话（我已经 +1 了他）。