c# - 在不允许任意实现时使用接口(interface)隐藏实现细节

Question

我正在使用 C# 为我们的应用程序构建一个公共(public) API。我在与 WCF 客户端一起使用的 DTO 之上有一组外观类。它允许 API 使用者从数据库应用程序中获取、更新、创建等。标准的东西:Customer 有一个 Orders 的集合，Order 有一个 Line Items 的集合，等等。

外观类都派生自一个公共(public)基类，并覆盖执行验证、读取/写入 DTO 和其他管道内容的方法，所有这些都使用各种内部类型。我正在使用工厂来创建新对象和获取现有对象。

现在的问题是如何最好地通过 API 公开类，同时最大限度地减少实现细节的公开。

接口(interface)似乎是一种显而易见的方法，是限制公开内容的最简单方法(并且最终可能无论如何都是必要的，因为正在考虑与 COM 兼容的接口(interface))。接口(interface)方法的问题在于，在内部我的代码将依赖于接口(interface)的特定实现。

假设我有一个 ICustomer 接口(interface)公开我的 CustomerFacade，IOrder 公开 OrderFacade。在外部，ICustomer 有一个 IOrders 集合。但在内部，CustomerFacade 有一组 OrderFacade。如果客户端应用程序向客户添加新的 IOrder，我必须检查 IOrder 是否真的是以前从我的工厂创建的 OrderFacade，而不是我控制之外的其他实现 IOrder 的对象。那是因为在内部我需要一个订单来做比 IOrder 可以做的更多的事情。

实际上，这并不重要——API 的用户不会尝试创建他们自己的 Order 实现。但这对我来说感觉不雅，就像滥用接口(interface)契约的本意一样。

直接公开外观类并不好，因为必须公开整个类层次结构，以及 protected 方法使用的内部类型，这会使 API 中包含消费者不会使用的类型，并且不需要知道。

我能想到的另一种选择是另一层封装:包含私有(private) OrderFacade 且仅公开应该公开的成员的 Order。但这似乎是为了有限的利益而编写的大量额外代码。

我考虑过抽象基类，但由于继承结构，这并不比公开外观类更好。例如，如果我有一个继承自 CatalogItem 的 ServiceItem，在两者之间引入抽象 ServiceItemBase 仍然需要我公开 CatalogItem 中的所有 protected 方法。

对这些方法有什么建议，或者我没有看过的替代方法吗？

Answer 1

这看起来很复杂。我不知道你要解决的业务问题，所以我不知道为什么需要各种门面。如果用户将使用您的 api 进行数据操作，您可以考虑使用命令来修改数据，并使用查询返回仅包含客户端所需数据的 DTO。

http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613

这是一本很棒的书，可能会有所帮助。