我前段时间问了一个问题，当我徘徊时，如果最好将一个大型项目（.NET类库）拆分成多个.NET DLL。建议是有一个大的DLL。
此DLL现在用于另一个项目。另一个项目只使用了几个类，因此项目中有很多未使用的类。
从架构的角度来看，这是一个不好的做法，有一个DLL还是我在想这个？
答案 0 :(得分：3)
拥有单独的dll有一定的利弊： -
<强>缺点： -
性能和复杂性可能会增加。
<强>优点： -
代码重用和层组织
您可能还有兴趣查看 articles on good design （首发五是关于SOLID原则。其余的是关于如何构建您的dll）
修改： -
您将有兴趣阅读 MSDN： -
首选单个大型装配而不是多个较小装配
为了帮助减少应用程序的工作集，您应该更喜欢 单个较大的组件而不是多个较小的组件。如果 你有几个总是装在一起的组件 应该将它们组合起来并创建一个组件。
与多个较小的组件相关的开销可以是 归因于以下内容：
•为较小的程序集加载元数据的成本。
•触摸CLR中预编译图像中的各种存储页面 加载程序集（如果它是使用Ngen.exe预编译的）。
•JIT编译时间。
•安全检查。因为你只支付你的记忆页面 程序访问，较大的程序集提供本机图像生成器 实用程序（Ngen.exe）有更大的机会优化本机映像 它产生。更好的图像布局意味着必要的数据可以 布局更加密集，这反过来意味着更少的整体页面 与多个布局相同的代码相比，需要完成这项工作 组件。
有时你无法避免分裂组件;例如，为 版本控制和部署原因。如果您需要运送类型 另外，您可能需要单独的组件。
注意： -
.Net DLL是程序集，但反之则不然。
答案 1 :(得分：2)
我倾向于将层分割成几个项目/ DLL，即使对于小项目也是如此。首先，它有助于保持您的关注点分离 - 例如，如果您的业务层无法与数据库通信，但只能与您的存储库项目通信，那么您可以保证您将通过适当的路径
使用相同的概念，您可以从一层到另一层公开接口，而不会暴露底层类。这有助于您按合同进行编码，因为一个层不能直接与另一个层中的类对话，但必须使用其接口，该接口通过像Ninject这样的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，因此无法获得直接引用。另一种方法是将接口和实现保存在两个独立的项目中，调用者只能直接引用interfaces项目。
它只是让你诚实。
但是如果你根本没有理由使用接口 - 例如，如果你不打算嘲笑你的数据库或切换到实现相同接口的不同层 - 那么我只想说将它们排除在外完全。只有具有接口的代码才能为您提供某种潜在的好处，否则您只是无缘无故地增加复杂性。
答案 2 :(得分：1)
将任何给定项目拆分为不同的图层是一种很好的做法。 UI，数据和业务逻辑是常见的分离线（MVC是其中的一个版本）。如果您的项目有多个这样的问题全部混在一起，那么将它拆分可能是个好主意。
性能不是真正的问题 - 它更多的是代码可维护性。
答案 3 :(得分：0)
你是在思考它。如果所有DLL都包含逻辑，那么按照今天的标准它将是一个非常小的文件，任何未使用的类都不会占用任何内存空间。
如果您要部署和跟踪的文件较少，也可以保持整洁。