“编码到接口”和业务实体的最佳实践？

Question

是否应该使用接口和/或基类来抽象业务实体，以便在传递它们时只使用接口/基类？ （这是我们一直在做的）。

还是不应该使用接口抽象实体，只在必要时使用继承？

我问这个问题的原因是，我总是尽可能地使用接口抽象出我的应用程序代码的所有部分。这使我可以轻松地使用模拟等执行单元测试。此外，通过使用接口，我可以确保只有工厂类实际引用了包含实现的项目，而所有其他（例如：业务逻辑层）仅被引用包含所有接口的项目。

到目前为止，上述方法运行良好。但是现在，我们需要通过 WCF 公开我们的一些业务方法。用于返回接口的业务方法，但现在我试图重用相同的方法并通过 WCF 公开它，WCF 不喜欢我使用和返回接口作为服务方法参数的一部分这一事实。

现在我可以尝试使用 KnownTypes 和 ServiceKnownTypes 解决问题，但它让我想到，如果我不为应用程序的业务实体部分使用接口，我就不会遇到这个问题。

所以我想知道在新项目方面是否有最佳实践：您是否应该为所有业务实体提供接口？

Answer 1

您实际上可以告诉 WCF 使用您的接口，所以这不是问题。

这是“添加服务引用”对话框中的设置。

您正在寻找的是“在引用的程序集中重用类型”选项。

您希望确保您的合同在线路的两端都使用，因此您需要确保您已选择重用参考程序集，并且您需要确保您的程序集在参考中程序集列表。

http://msdn.microsoft.com/en-us/library/bb514724.aspx

要绕过必须了解子类的基类，您可以执行以下操作：

[KnownType("GetKnownTypes")]
public abstract class Shape
{
    static Type[] GetKnownTypes()
    {
        //do some reflection here to look up all classes that extend Shape
        //and are serializable
        return results;
    }
}

我不确定您是否可以对接口使用相同的方法，因为它需要静态方法实现。