我一直在考虑重构一个相当广泛的类/实用程序库的方法，而我认为我想要做的一件事是拆分任何引入新依赖项的更高级别的辅助工具。我在这里阅读了一些以前的问题，我特别注意到的是关于Microsoft如何在DLL中自由使用命名空间的评论。给出的示例是System.Web - 它位于基础框架中，但是如果您需要，还有一个System.Web.dll可以为命名空间添加更多功能。
我还注意到其他几个System.Web.* DLL可用，我想知道是否有一个原因导致它们不会被合并到一个DLL中。可能是因为他们有自己独立的依赖关系而微软（像我一样）想要沿着那些线分开组件？还是为了更容易维护？还有其他什么呢？
答案 0 :(得分：3)
他们不是1 .dll的原因是因为框架的不同版本。
版本2.0下的System.Web
System.Web.Abstractions， System.Web.DymanicData， System.Web.DymanicData.Design， 等。 。 。 System.Web.Extensions程序
都是在3.5框架下编写的。
如果您将System.Web更改为1 .dll，然后所有用户都必须更改.NET 3.5框架，则IIS仍使用2.0。
答案 1 :(得分：2)
嗯，可能还有其他答案，但对我来说最重要的是安全角度。您授予程序集的权限，而不是名称空间。这将允许您通过命名空间逻辑分组类，但是具有访问在程序集中组合在一起的资源的类。
哦，您还可以使用语言中性程序集，允许您在不同的程序集中对依赖于语言的例程进行分组。
答案 2 :(得分：1)
许多System.web程序集仅在ASP.net服务器处理和提供页面或Web服务时才使用。它们通常不是客户端.Net应用程序所必需的，并且不包含在.Net Client Profile中;一个简洁的.Net框架版本。 （参考：http://msdn.microsoft.com/en-us/library/cc656912.aspx）