【问题标题】：Proper .NET DLL structure for app应用程序的正确 .NET DLL 结构
【发布时间】：2008-11-23 18:21:18
【问题描述】：
...如果有这样的事情。这是在 .NET 应用程序中构建 DLL/引用的两种方法的图像：http://www.experts-exchange.com/images/t80668/compArch.png。该应用程序可以是网站（在这种情况下）或 winform。每个框代表一个 DLL。对于 winform 应用，只需将“webcontrols”替换为“winformcomponents”即可。
第一个（顶部）图像是我喜欢的。您可能想要扩展“一些”基本 Web 控件并直接使用其他控件。第二张图片使您可以通过界面扩展任何 Web 控件。对我来说，这似乎有点矫枉过正，因为您可能只想简单地使用已经存在的东西而无需修改。哪个更好，有什么优点/缺点？
第一个图像将最低的通用结构（异常、fileIO、常量等）放入 common.dll 中。第二张图片将应用程序业务逻辑和通用放入一个 DLL 中。哪个更好，每种方法的优点/缺点是什么？
【问题讨论】：
标签：
c#
.net
asp.net
architecture
【解决方案1】：
拥有大量引用通常是不好的，因为加载 DLL 的成本不可忽略。它可能没有那么优雅，但是更少的模块可以提高你的性能。在我们的工艺中，您必须在完全模块化的优雅与严酷的性能现实之间找到平衡。在我们的工艺中，像往常一样，在您开始分析以衡量应用程序的性能之前，您不会知道什么是平衡。
【解决方案2】：
我认为这真的取决于程序员的偏好。
这一切都归结为依赖关系。一个 DLL 中的更多内容意味着它自然会在该 DLL 上创建更多的依赖项。
出于以下原因，我个人倾向于遵循与 MS 结构类似的路线：
- 它使自定义“框架”的新手更容易找到他们想要的东西（例如
CompName.Web.UI 和CompName.Data。
- 它有助于减少对“显而易见”选择的依赖。我不太喜欢
CompName.Common 类型的 DLL，因为它没有明确指出可能的依赖项，而 CompName.Web.UI 表明它可能被任何网络应用程序使用。
- 大小明显减小，因为 DLL 内容将更加“相关”。
应用程序内层的 DLL 是有意义的，其中的类型应仅是业务模型所需的类型，其他对象（例如实用程序、数据访问等）应在其自己的库中。