2

前段时间，当我徘徊时，我在这里问了一个问题，将一个大型项目（.NET 类库）拆分为多个 .NET DLL 是否更好。建议是拥有一个大型 DLL。

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

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

4

4 回答 4

4

拥有单独的 dll 有一定的优点和缺点：-

缺点：-

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

优点：-

代码重用和分层组织

您可能也有兴趣查看有关良好设计的文章（前五篇是关于 SOLID 原则。其余的是关于如何构建 dll 的）

编辑：-

您将有兴趣阅读此MSDN：-

首选单个大型组件而不是多个较小的组件

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

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

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

• 在 CLR 中触摸预编译映像中的各种内存页面以加载程序集（如果它是使用 Ngen.exe 预编译的）。

•JIT 编译时间。

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

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

笔记：-

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

于 2013-09-17T20:51:39.710 回答
2

即使对于小型项目，我也倾向于将这些层分成几个项目/DLL。一方面，它有助于保持关注点分离 - 例如，如果您的业务层无法与数据库通信，而只能与您的存储库项目通信，那么您可以保证您将通过适当的路径.

使用相同的概念，您可以逐层公开接口，而无需公开底层类。这有助于您按合同进行编码，因为一层不能直接与另一层中的类对话，但必须使用其接口，该接口通过 IoC 库（如 Ninject）连接。

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

编辑

关于评论：

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，因此它永远无法获得直接参考。另一种选择是将您的接口和您的实现保留在两个单独的项目中，并且调用者将只有对接口项目的直接引用。

它只是让你诚实。

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

于 2013-09-17T20:55:03.423 回答
1

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

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

于 2013-09-17T20:54:50.237 回答
0

你想多了。如果 DLL 包含的所有内容都是逻辑，那么按照今天的标准，它将是一个非常小的文件，并且任何未使用的类都不会占用任何内存空间。

如果您要部署和跟踪的文件较少，您也会使事情变得更整洁。

于 2013-09-17T20:48:47.277 回答