有多糟糕?我已经阅读了无数文章,并且以前从未创建过带有行为的抽象 DataContract,但似乎这样做可以解决我遇到的一个问题,该问题将阻止我在任何地方创建工厂来确定子类实现。我的问题是,如果我决定在我的数据合同中添加行为,我会受到惩罚吗?当然,它们不能被使用,并且在调用存储库调用和数据被持久化之前,它们可以执行特定于该子类类型的某些操作。我可以为每个子类创建“管理器”类,但这让我回到工厂,我正在尝试一种更加多态的方法。提前致谢。
4 回答
您可以将所需的所有行为添加到数据合同中。您应该清楚地记录客户看不到该行为的事实,否则以后有人会感到失望。还要记录一个事实,即必须注意不要将任何依赖于实现的数据添加到数据合同中,因为它不是您想要传递给客户端的任何内容。
总而言之,我认为您最好让数据合约成为数据合约,并将行为排除在外。
为什么你不能以经典的方式创建你的数据契约(MyDataContract),只是数据字段,没有别的,然后从中派生你的行为类?
public class BehaviorialClass : MyDataContract
{
.....
}
这样,您就有了一个很好、干净的关注点分离,您的数据合约不会被它无法真正处理的行为“污染”......
马克
将行为直接放在 DataContracts 中的一个很好的折衷方案是将行为定义为与 Contracts 相同的程序集或完全不同的程序集中的扩展方法。可选地,扩展方法可以放置在与合约分开的命名空间中,以进一步隔离数据和行为的分离。
这样一来,您的合同就会保持干净,但同时,合同的 .NET 使用者可以轻松地导入与这些 DataContracts 相关的附加功能。
在某些时候,您会想要使用 MemberwiseClone 并实现接口,而不需要不必要的中间数据转换(更糟糕的是,不必要的维护)。扩展方法适用于当您实际上无法控制对象定义但仍需要面向对象的流畅性时;他们在任何其他情况下都增加了繁忙的工作,并且分散了比 C/C++ 更糟糕的类定义。逆“趋势”做对你有用的事,你可能会发现一种改变整个球赛的模式(比如 Jeffrey Richter 的 AsyncEnumerator)。