适用于app的.NET DLL结构

Question

......如果有这样的话。这是在.NET应用程序中构造DLL /引用的两种方法的图像：http://www.experts-exchange.com/images/t80668/compArch.png。该应用程序可以是一个网站（在这种情况下）或winform。每个框表示一个DLL。对于winform应用程序，只需将“webcontrols”替换为“winformcomponents”。

第一个（顶部）图像是我喜欢的。您可能希望扩展“部分”基本Web控件并直接使用其他控件。第二个图像使您可以通过界面扩展任何Web控件。对我来说，这似乎有点过头了，因为你可能想要简单地使用已有的东西而不进行修改。哪个更好，有哪些优点/缺点？

第一个图像将最低常见结构（例外，fileIO，常量等）放入common.dll。第二个图像将应用程序业务逻辑和通用放入一个DLL中。哪个更好，每个apporach的优点/缺点是什么？

Answer 1

拥有大量引用通常很糟糕，因为加载DLL具有不可忽略的成本。它可能不那么优雅，但拥有更少的模块可以提高您的性能。在我们的工艺中，你必须找到完全模块化的优雅与性能的残酷现实之间的平衡。和往常一样，在您开始进行分析以衡量应用程序性能之前，您不会知道什么是平衡。

Answer 2

我认为这完全取决于程序员的偏好。

这一切都归结为依赖关系。一个DLL中的更多东西意味着它自然会在该DLL上创建更多的依赖者。

由于以下原因，我个人倾向于遵循类似的MS结构：

• 使新手更容易通过自定义“框架”找到他们想要的内容（例如CompName.Web.UI和CompName.Data。
• 它有助于减少对“明显”选择的依赖性。我对CompName.Common类型的DLL不太热衷，因为它没有明确指出可能的依赖项，而CompName.Web.UI表明它很可能被任何网络应用程序使用。
• 明显减小尺寸，因为DLL内容会更“相关”。

应用程序中的层的DLL是有意义的，其中的类型应该只是业务模型所需的类型，其他对象（例如实用程序，数据访问等）应该在它们自己的库中。