我正在使用 C# 为我们的应用程序构建一个公共 API。我在与 WCF 客户端一起使用的 DTO 之上有一组外观类。它允许 API 使用者从数据库应用程序中获取、更新、创建等。标准的东西：客户有一个订单的集合，订单有一个行项目的集合，等等。
外观类都派生自一个公共基类，并覆盖执行验证、读取/写入 DTO 和其他管道的方法，所有这些都使用各种内部类型。我正在使用工厂来创建新对象并获取现有对象。
现在的问题是如何最好地通过 API 公开类，同时最大限度地减少实现细节的公开。
接口似乎是一种显而易见的方法，是限制暴露内容的最简单方法（并且最终可能无论如何都是必要的，因为正在考虑使用与 COM 兼容的接口）。接口方法的问题在于，在内部我的代码将依赖于接口的特定实现。
假设我有一个公开我的 CustomerFacade 的 ICustomer 接口，以及公开 OrderFacade 的 IOrder。在外部，ICustomer 有一个 IOrder 集合。但在内部，CustomerFacade 有一个 OrderFacade 集合。如果客户端应用程序向客户添加新的 IOrder，我必须检查 IOrder 是否真的是以前从我的工厂创建的 OrderFacade，而不是我控制之外的其他实现 IOrder 的对象。那是因为在内部我需要一个订单来做比 IOrder 可以做的更多的事情。
实际上，这并不重要——API 的用户不会尝试创建自己的 Order 实现。但这对我来说感觉很不雅，就像滥用接口契约的含义一样。
直接暴露外观类并不好，因为必须暴露整个类层次结构，以及受保护方法使用的内部类型，这会使 API 与消费者不会使用和不使用的类型混淆需要了解一下。
我能想到的另一种选择是另一层封装：一个包含私有 OrderFacade 并且只公开应该公开的成员的订单。但这似乎是为了有限的利益而增加了很多额外的代码。
我考虑过抽象基类，但由于继承结构，这并不比暴露外观类更好。例如，如果我有一个继承自 CatalogItem 的 ServiceItem，在两者之间引入一个抽象的 ServiceItemBase 仍然需要我在 CatalogItem 中公开所有受保护的方法。
关于这些方法的任何建议，或者我没有看过的替代方法？