几个很大或很小的dll

Question

我们正在讨论如何设计我们的应用程序。

使相对较大或使用很多专用dll。

有时我们在不同的产品中使用我们的dll。

.net环境下的常见做法是什么。

这里的加载时间真的如此不同吗？

Answer 1

我从来没有真正意识到许多.NET开发人员似乎都持有这种“很多引用=糟糕”的想法。老实说，我认为更好的分离是一件好事，特别是当您获得将代码重用于其他项目的好处时。

如果你看一下Rails或Django社区，我们非常鼓励，甚至有点期望你将你的应用程序分成小的可重用部分。确实没有任何缺点，但有很多好处。通常你的代码更清晰，因为你必须以逻辑单位来思考。

在.NET社区中，我看到很多人只是想将所有内容都塞进一个单片DLL中，而且我认为这是错误的。为什么项目参考不好？为什么拥有各自处理自己独特任务的微库是不好的？答案是，它一点都不差。我们应该接受分离关注和干旱原则。

Answer 2

  

这里的加载时间真的如此不同吗？

这应该不是决定因素。相反，请关注您的产品如何使用DLL中的功能，以及不同库中的逻辑分离。

就个人而言，我会根据用途设计你的类库结构。

有两个相互竞争的目标，适当的平衡取决于您将如何使用这些库。

• 较少的分离（较少的库）通常会使开发更容易，维护更容易。
• 更多分离（更多dll）带来更大的灵活性，并且可能更小的部署，因为不同的产品可以挑选他们想要的东西。

如果每个库的“功能”通常都是唯一的，我倾向于尽可能少地使用库。如果需要大的依赖关系，我将尝试将其隔离到库中以避免必须部署该依赖关系。

Answer 3

我们公司最初采用制作许多DLL的方法。我们发现它会产生严重的维护问题。现在我们正朝着更少的DLL发展。这意味着当不同的产品使用我们常见的组件时，他们通常会有比他们可能需要的更多的类，但这不是一个可怕的问题。

Answer 4

这里没有真正具体的答案。一般而言，与更少的紧耦合单片模块相比，倾向于更小/松散耦合的模块是件好事。就个人而言，我不担心运行时开销，因为与应用程序的设计/体系结构相比，它并不重要。