单个DLL V多个DLL

Question

前段时间我在这里问了一个问题，当时我在想，将一个大型项目(.NET类库)拆分为多个.NET DLL是否更好。建议使用一个大的DLL。

此DLL现在用于另一个项目中。另一个项目只使用了几个类，因此项目中有许多未使用的类。

从架构的角度来看，拥有一个DLL是不好的做法，还是我想得太多了？

Answer 1

拥有独立的dll有一定的利弊：

缺点：-

性能和复杂性可能会增加。

优点：-

代码重用和层组织

您可能还有兴趣查看 (开始的五个是关于可靠原则的。剩下的部分是关于如何构造dll的)

编辑：-

您将有兴趣阅读此:-

更喜欢单个大程序集，而不是多个小程序集

为了帮助减少应用程序的工作集，您应该首选单个较大的程序集，而不是多个较小的程序集。如果您有几个始终一起加载的程序集，则应将它们组合在一起并创建单个程序集。

与拥有多个较小程序集相关的开销可以归因于以下几个方面：

·为较小的程序集加载元数据的成本。

·接触CLR中预编译映像中的各种内存页，以便加载程序集(如果它是用Ngen.exe预编译的)。

·JIT编译时间。

·安全检查。由于您只需为程序访问的内存页付费，因此较大的程序集为本机映像生成器实用程序(Ngen.exe)提供了更多优化其生成的本机映像的机会。更好的图像布局意味着必要的数据可以更密集地布局，这反过来意味着与在多个程序集中布局相同的代码相比，需要更少的总页面来完成这项工作。

有时，您无法避免拆分程序集；例如，出于版本控制和部署的原因。如果需要单独发布类型，则可能需要单独的程序集。

备注：-

.Net DLL是程序集，但反之亦然。

Answer 2

我倾向于将这些层划分为几个项目/DLL，即使对于小项目也是如此。首先，它有助于保持您的关注点分离-例如，如果您的业务层无法与数据库对话，而只能与您的存储库项目对话，那么您将确保通过适当的路径。

使用相同的概念，您可以逐层公开接口，而无需公开底层类。这有助于您按照约定编写代码，因为一层不能直接与另一层中的类对话，而必须使用它的接口，该接口是通过IoC库连接的。

随着项目的发展，如果您有多个开发人员在一个项目中工作，那么将它们分开也是很好的。你可以有一个前端开发人员，一个服务开发人员，一个数据库开发人员，等等，他们永远不会发生冲突，因为他们是在完全不同的项目上工作。

编辑

关于这条评论：

1)你仍然可以通过DI在一个层中使用接口。一个简单的例子是：

public interface IUserManager{}
internal class UserManager : IUserManager{}

public interface ICustomerManager{}
internal class CustomerManager : ICustomerManager {
    private readonly IUserManager _userManager;
    public CustomerManager(IUserManager userManager) {
        // DI library automatically populates this object
        _userManager = userManager;
    }

    void SomeMethod() {
        var user = _userManager.GetUser(42);
    }
}

2)我要说的是，如果你不厌其烦地使用接口，那么就一直使用它们，不要让自己选择不使用它们。例如：

// Repository project
public interface IUserRepository{}
internal class UserRepository : IRepository{}

业务项目只知道IUserRepository，不知道UserRepository，所以它永远不可能获得直接引用。另一种选择是将接口和实现放在两个单独的项目中，调用方将只有一个对接口项目的直接引用。

它只会让你保持诚实。

但是，如果您根本没有理由使用接口-例如，如果您不打算模拟您的数据库或切换到实现相同接口的不同层-那么我只能说完全不使用它们。只有在提供某种潜在好处的情况下，才能使用接口编写代码，否则您只是无缘无故地增加复杂性。

Answer 3

将任何给定的项目分成不同的层是一种很好的做法。UI、数据和业务逻辑是常见的分界线(MVC是其中的一个版本)。如果您的项目有多个像这样的问题混合在一起，那么将其拆分可能是一个好主意。

性能并不是真正的问题--它更多的是关于代码的可维护性。