我应该有一个单独的接口组件吗? [英] Should I have a separate assembly for interfaces?

问题描述

我们目前在一个项目中有很多类，并且这些类中的每一个都实现了一个接口，主要是出于 DI 的原因.

We currently have quite a few classes in a project, and each of those classes implement an interface, mostly for DI reasons.

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

Now, my personal feeling is that these interfaces should be put into a separate namespace within the same assembly (so we have a MyCompany.CoolApp.DataAccess assembly, and within that there's an Interfaces namespace giving MyCompany.CoolApp.DataAccess.Interfaces).

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

However, somebody has suggested that these interfaces should actually be in their own assembly. And my question is - are they right? I can see that there are some benefits (eg. other projects will only need to consume the interface assembly), but at the end of they day all of these assemblies are going to need to be loaded. It also seems to me that there could be a slightly more complex deployment issue, as Visual Studio will not automatically pull the implementing assembly into the target's bin folder.

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

Are there best practice guidelines for this?

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

To make my point a little clearer: We already separate UI, DataAccess, DataModel and other things into different assemblies. We can also currently swap out our implementation with a different implementation without any pain, as we map the implementing class to the interface using Unity (IOC framework). I should point out that we never write two implementations of the same interface, except for reasons of polymorphism and creating mocks for unit testing. So we don't currently "swap out" an implementation except in unit tests.

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

The only downside I see of having the interface in the same assembly as the implementation is that the whole assembly (including the unused implementation) will have been loaded.

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

I can, however, see the point that having them in a different assembly means that developers won't accidentally "new" the implementing class rather than have it created using the IOC wrapper.

我从答案中没有理解的一点是部署问题.如果我只是依赖于接口程序集，我会有一个类似于以下结构的东西:

One point I haven't understood from the answers is the deployment issue. If I am just depending on the interface assemblies, I'll have a something like the following structure:

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

当我构建这个时，自动放入 bin 文件夹的程序集就是那​​些接口程序集.但是，我在统一中的类型映射将不同的接口映射到它们的实际实现.包含我的实现的程序集如何最终出现在 bin 文件夹中?

When I build this, the assemblies that are automatically put into the bin folder are just those interface assemblies. However, my type mappings in unity map different interfaces to their actual implementations. How do the assemblies that contain my implementations end up in the bin folder?

推荐答案

到目前为止的答案似乎表明，将接口放在自己的程序集中是通常"的做法.我不同意将不相关的接口放入一个共享"公共程序集，因此这意味着我需要为每个实现"程序集拥有 1 个接口程序集.

The answers so far seem to say that putting the interfaces in their own assembly is the "usual" practice. I don't agree with putting unrelated interfaces into one "shared" common assembly, so this would imply I will need to have 1 interface assembly for each "implementation" assembly.

但是，进一步考虑，我想不出许多现实世界的这种做法的例子(例如，做 log4net 或 NUnit 提供公共接口组件，以便消费者可以决定不同的实现?如果是这样，我可以使用什么其他的 nunit 实现?).我花了很长时间浏览谷歌，找到了很多资源.

However, thinking about it further, I can't think of many realy world examples of this practice (eg. do log4net or NUnit provide public interface assemblies so that consumers can then decide on different implementations? If so, what other implementation of nunit can I use?). Spending ages looking through google, I've found a number of resources.

• 拥有单独的程序集是否意味着松散耦合?以下建议不:

• Does having separate assemblies imply loose coupling? The following suggests no:

http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies

http://codebetter.com/blogs/jeremy.miller/archive/2008/09/30/separate-assemblies-loose-coupling.aspx

我从谷歌搜索中发现的普遍共识是，越少的程序集越好，除非有充分的理由添加新的程序集.另请参阅:

The general consensus that I could find from googling was that fewer assemblies is better, unless there's a really good reason to add new assemblies. See also this:

http://www.cauldwell.net/patrick/blog/ThisIBelieveTheDeveloperEdition.aspx

由于我没有生成公共 API，并且我已经将接口放入它们自己的命名空间中，因此 不 盲目地创建新程序集是有意义的.这种方法的好处似乎超过了添加更多程序集的潜在好处(我不太可能真正获得好处).

As I am not producing public APIs, and I'm already putting interfaces into their own namespaces, it makes sense not to blindly create new assemblies. The benefits of this approach seem to outweigh the potential benefits of adding more assemblies (where I'm unlikely to ever actually reap the benefits).

这篇关于我应该有一个单独的接口组件吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！