在业务层有[DataContract]标记类是一个坏的设计吗?

所以正如我在评论中所说的:

如果你觉得它不好，那就引入一个由那个类实现的接口，并在你的业务层中使用它。注意，DataContract属性仅仅是序列化引擎的标记。

我发现这是一个有用的答案。基本上，您的POCO可以由DataContractSerializer序列化，而无需添加[DataContract]属性。

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

如果另一种选择是几乎将合约复制到另一个"BL类"中，只是为了让您对不将数据合约发送到特定层感觉更好-我会说不要发送数据合约。

同样，"请求"、"命令"answers"数据传输对象"并不是严格意义上的"facade"对象(或模式)。您可以在DAL API中使用请求对象(我假设是分层架构)，以便简化方法签名并支持将来的重构，对吗?那么为什么不在所有层中使用相同的请求对象呢?

如果在实际的DataContract属性方面存在部署问题(我想不出任何问题)，那就是另一回事了。

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

如果以上两种情况都不适合你，我会说继续按照@Rahal在他的评论中所说的去做(我已经+了他)