我应该有接口，一个单独的程序？ [英] 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 组装，并在内部这有一个接口给命名空间 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?

编辑：

为了使我的观点更清晰一点：我们已经独立的用户界面，数据访问，的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.

我可以，但是，看到，让他们在不同的组件，意味着开发商不会意外新的实现类，而不是把它创建使用国际奥委会的包装。

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

<一个href="http://$c$cbetter.com/blogs/jeremy.miller/archive/2008/09/30/separate-assemblies-loose-coupling.aspx"相对=nofollow称号=单独的程序集！=松coupling">http://$c$cbetter.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/帕特里克/博客/ 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屋！