.net - 我应该有一个单独的接口(interface)组件吗？

Question

我们目前的项目中有相当多的类，并且每个类都实现一个接口(interface)，主要是出于 DI 的原因。

现在，我个人的感觉是，这些接口(interface)应该放入同一程序集中的单独命名空间中(因此我们有一个 MyCompany.CoolApp.DataAccess 程序集，其中有一个 Interfaces 命名空间提供 MyCompany.CoolApp.DataAccess.Interfaces)。

但是，有人建议这些接口(interface)实际上应该位于它们自己的程序集中。我的问题是——他们是对的吗？我可以看到有一些好处(例如，其他项目只需要使用接口(interface)程序集)，但最终所有这些程序集都需要加载。在我看来，可能存在稍微复杂的部署问题，因为 Visual Studio 不会自动将实现程序集拉入目标的 bin 文件夹中。

是否有这方面的最佳实践指南？

编辑:

为了让我的观点更清楚一点:我们已经将 UI、DataAccess、DataModel 和其他东西分离到不同的程序集中。目前，我们还可以轻松地将我们的实现替换为不同的实现，因为我们使用 Unity(IOC 框架)将实现类映射到接口(interface)。我应该指出，除了出于多态性和为单元测试创​​建模拟的原因之外，我们永远不会编写同一接口(interface)的两个实现。因此，除了单元测试之外，我们目前不会“交换”实现。

我认为将接口(interface)与实现放在同一程序集中的唯一缺点是整个程序集(包括未使用的实现)都将被加载。

但是，我可以看到，将它们放在不同的程序集中意味着开发人员不会意外地“新建”实现类，而不是使用 IOC 包装器创建它。

我从答案中没有理解的一点是部署问题。如果我只依赖于接口(interface)组件，我将拥有类似以下结构的内容:

MyCompany.MyApplication.WebUI
    References:
        MyCompany.MyApplication.Controllers.Interfaces
        MyCompany.MyApplication.Bindings.Interfaces
        etc...

当我构建这个时，自动放入 bin 文件夹的程序集只是那些接口(interface)程序集。然而，我在统一中的类型映射将不同的接口(interface)映射到它们的实际实现。包含我的实现的程序集如何最终出现在 bin 文件夹中？

Answer 1

通常 预期^？实践是将它们放在自己的程序集中，因为这样使用这些接口(interface)的给定项目不需要对实现的硬引用那些接口(interface)。从理论上讲，这意味着您可以轻松地更换实现。

也就是说，我不记得上次这样做是什么时候，就 @David_001 的观点而言，这不一定是“通常的”。我们倾向于让我们的接口(interface)与实现保持一致，这是我们测试接口(interface)的最常见用途。

我认为根据您所生产的产品可以采取不同的立场。我倾向于生成 LOB 应用程序，这些应用程序需要与其他应用程序和团队进行内部互操作，因此任何给定应用程序的公共(public) API 都有一些利益相关者。然而，这并不像为许多未知的客户端生成库或框架那么极端，公共(public) API 突然变得更加重要。

在部署场景中，如果您更改了实现，理论上您可以只部署该单个 DLL - 这样就可以单独保留 UI 和接口(interface) DLL。如果您将接口(interface)和实现一起编译，则可能需要重新部署 UI DLL...

另一个好处是代码的干净隔离 - 拥有一个接口(interface)(或共享库)DLL 向开发团队中的任何成员明确指出在哪里放置新类型等。 我不再计数这是一个好处，因为我们没有遇到任何不这样做的问题，无论接口(interface)放置在哪里，仍然可以轻松找到公共(public)合约。

我不知道是否存在支持或反对的最佳实践，可以说重要的是在代码中，您始终使用接口(interface)并且永远不会让任何代码泄漏到使用实现中。