有很多文档涉及设计模式（例如访客），SOLID（单一责任等），KISS（保持简单，愚蠢），分层设计等。
我不完全理解的一件事是如何在扩展应用程序时决定何时需要新的项目/ DLL。是否有使用的标准？
例如，System.Windows.Forms（http://msdn.microsoft.com/en-us/library/system.windows.forms.containercontrol.aspx）是System.Windows.Forms.dll的一部分，但它派生自System.MarshalByRefObject，它是mscorlib.dll的一部分。
答案 0 :(得分：4)
您正在混合程序集（DLL）和名称空间。
Assemblies是包含类等实现的二进制文件。
Namespaces只是将类，枚举等组织到逻辑组中的一种方法，以防止从每个级别访问每个类，并防止命名冲突（例如System.Windows.Forms.Timer和{{ 1}}）。
System.Threading.Timer 从System.Windows.Forms System System任何人都可以在System命名空间中放置任何内容 - 即使你可以做到。它只是System的子命名空间。
将一部分代码分解为单独的程序集有几个原因。一个重要的是可重用性。如果您有一些常用的控件或实用程序，则可以将其保存在自己的DLL中，并在项目中使用它而无需复制和粘贴代码。
答案 1 :(得分：1)
不要将层与层混淆。分层代码几乎总是必须的。但是，将代码拆分为单独的物理层，在实际需要之前通常不希望这样做（遵循KISS原则）。
如果你正确地分层你的代码，那么当你需要将它分解成单独的层时，这样做应该是一个非常无痛的过程。但是，如果您从未正确地对代码进行分层，那么您会发现拆分层将非常困难。
作为一个简单的例子，假设您创建一个登录表单，并假设您将所有逻辑收集到系统信息，访问数据库，验证用户凭据以及构建权限，所有这些都直接进入WinForm类。我刚刚描述的代码只有1层，只有1层。如果您发现自己需要使用ASP.NET创建基于Web的登录页面，您会发现重用现有代码非常困难。使用基于Web的登录，您至少需要将UI逻辑与业务/数据访问逻辑分开，但由于它们都直接位于WinForm类中，因此无需重新分解代码就无法使用。
现在，让我们说，您没有将所有代码放在表单中，而是花时间将其正确分层。假设你打破了访问数据库的所有代码，将它全部放入数据访问类中。然后，您将所有业务逻辑代码放在业务类中。此时，WinForm类中的实际代码应限于除UI相关逻辑之外什么也不做，例如处理控件事件，设置标签等。在第二个示例中。你仍然只有1层，但你有三个不同的独立层（即UI，业务，数据访问）。
如果您已经将代码分层，那么当您需要在基于Web的项目中重用它时，您可以轻松地将业务和数据访问层移动到类库（dll）中，然后在服务器端层的ASP.NET项目中重用它们。
在两种情况下，通常只需要将代码分解为单独的类库：
即使您将所有代码放在一个项目中，只要它是分层的，在出现这种情况时，将项目拆分为多个类库将非常容易。所以最大的设计问题不是你有多少DLL。相反，大的设计问题是你有多少层。一旦您将代码分层，就可以根据需要在不同项目之间移动它。
实际上，即使您不需要在项目之间重用代码也不需要支持n层，您仍然可以合理地选择将图层划分为单独的类库。纯粹出于组织目的或一致性这样做可能是有意义的。例如，如果另一个开发人员在你身后，看到一个名为“MyCompany.Feature.Business”的类库中的类，他们可以安全地假设这些类都是业务逻辑层的一部分。通过这种方式，将代码分解为单独的类库可以自我记录。
将代码放入dll还有其他原因。例如，它可以轻松支持插件架构，或者更容易一次更新应用程序的一部分。