如果有这样一件事。这是一个.NET应用程序中结构化DLL / 引用的两种方法的图像：http://www.experts-exchange.com/images/t80668/compArch.png。应用程序可以是网站（在本例中是网站）或winform。每个框代表DLL。对于winform应用程序，请将“webcontrols”替换为“winformcomponents”。
第一张（顶部）图像是我喜欢的。你可能想扩展一些基本Web控件，直接使用其他控件。第二张图像使您通过接口扩展任何Web控件。对我来说，这似乎有点过度，因为您可能要使用已经存在的控件而无需进行修改。哪个更好？有什么优缺点？
第一张图将最低通用结构（例如异常、文件I/O、常量等）放入 common.dll。第二张图将应用业务逻辑和 common 放入一个 DLL 中。哪个更好？每种方法的优缺点是什么？
通常具有大量引用是不好的，因为加载 DLL 具有不可忽略的成本。也许不够优雅，但模块少了会提高性能。在我们的工艺中，像往常一样，你必须找到完全模块化的优雅和性能残酷现实之间的平衡点。如我们的惯例所述，在开始分析应用程序性能之前，您不知道平衡点在哪里。
我认为这是一个程序员偏好的问题。
这实际上归结于依赖关系。一个 DLL 中有更多的内容意味着它自然会创建更多对该 DLL 的依赖关系。
基于以下原因，我个人倾向于沿用微软公司的结构：
CompName.Web.UI and CompName.Data.CompName.Common type DLL s because it does not clearly indicate possible dependents, whereas CompName.Web.UI suggests that it is likely to be used by any web apps.应用程序中的层次结构的DLL很有意义，其中的类型应该只是业务模型所需要的类型，其他对象（如实用程序，数据访问等）应该放在他们自己的库中。