我需要使用一个代表发送到我的 REST WCF 服务的客户端请求的类。
但我也想将此请求传递给我在业务层中的方法。 （目前它是 WCF 服务的一部分）
在业务层中有 [DataContract] 标记的类是一个糟糕的设计吗？
【问题讨论】：
DataContract属性只是序列化引擎的标记。
标签： c# .net wcf datacontract
正如我在评论中所说：
如果您对此感到不满意，请引入由该类实现的接口并在您的业务层中使用它。请注意，DataContract 属性只是序列化引擎的标记。
【讨论】：
我发现这是一个有用的答案。基本上，您的 POCO 可以通过 DataContractSerializer 序列化，而无需添加 [DataContract] 属性。
【讨论】：
DataContract 注释，并且没有一个成员用DataMember 装饰，那么DataContractSerializer 将尝试序列化该类的所有 成员。这可能是不可取的，因为它可能会向客户端显示出乎意料的数据。此外，如果您使用自动实现的属性，它们可能无法很好地序列化。检查实际上被序列化的内容以及它的样子很重要。
如果另一种选择是将合同几乎复制到不同的“BL 类”，只是为了让您对不将 DataContracts 发送到某个层感觉更好 - 我会说不要 - 发送 DataContract。
此外，“请求”、“命令”和“数据传输对象”并不是严格意义上的“外观”对象（或模式）。您可以在 DAL API 中使用请求对象（我假设是分层架构），以简化方法签名并启用未来的重构，对吗？那么为什么不在所有层中使用相同的请求对象呢？
如果存在与实际 DataContract 属性有关的部署问题（我想不出任何问题），那就另当别论了。
【讨论】：
如果将来您需要 REST WCF 客户端请求服务的不同接口并且您无法控制消费客户端，那么如果您的 BL 严重依赖 WCF 合同类，您可能会遇到问题.您可能很难在不破坏 BL 的情况下修改服务接口，或者在不破坏与客户的接口的情况下修改 BL。
如果以上都不适用于你，我会说继续@Rahal 在他的评论中所说的话（我已经 +1 了他）。
【讨论】：