.net 什么时候应该将层作为单独的部署单元来实现？

在设计应用程序时，各层（如表示、业务逻辑和数据访问）应在什么位置进行设计被分成不同的程序集？

主要是在不同的库中分配类，如果您希望以您可以选择的方式提供产品，那么最终用户将无法访问整个项目的类

考虑一下客户机-服务器应用程序。如果您有云计算场景，为什么要向客户分发服务器类？您更愿意分发表示和服务客户机类，它们打包在独立于服务器的程序集中。这也是一个很好的安全措施

在程序集中分离的另一个优点是避免将大型程序集加载到应用程序域（AppDomain）。例如，如果您的程序的使用不需要图像处理超时，但每天的单个操作可能需要成像类，则您可以节省处理时间（将大型程序集加载到应用程序域时）和内存，因为您的应用程序不需要具有所有和，最终，应用程序的内存使用率会降低

从体系结构的角度来看，在程序集中分离将强制实施良好的实践，这是因为您会意识到不要混合层，例如，您不应该在表示程序集中需要业务程序集，因此，没有人可以直接从用户界面访问业务逻辑

---

最后，在部署方面，您可以节省时间，因为您可以使用特定程序集更新模块化应用程序，从而简化上载过程或自动更新过程，因为下载时间减少，节省了网络流量。

就我个人而言，我喜欢在我的项目需要时拆分我的层，不需要放入不同的程序集，但需要放入不同的文件夹

当我需要在不同的项目中使用图层时，我会将不同的图层移动到不同的部件中

---

一旦层位于不同的程序集中，您就需要担心版本控制和排序问题，这可能会非常麻烦。

对于一个小项目，您的答案是正确的，但是，现在想象一下，您正在销售您的产品，因为您将它放在一个大的程序集中，您将向客户公开服务器端特定的细节，这些细节是您公司价值的一部分，因此您的客户可以使用您的“一体式组件”创建自己的客户机-服务器解决方案。当然，授权可以防止这种情况发生，但这是一个安全问题，因为他们可以轻松地对您的MSIL进行反向工程，查看您的代码如何工作，甚至发现安全问题……没错，这完全取决于创建的项目的类型和大小。我个人会使用WCF服务，并将我的业务逻辑与我的数据访问逻辑放在一起，前端只有非常基本的逻辑，很可能是所有层都使用的实体层。对于较小的项目，虽然我看不到客户会花时间真正分解项目，看看它是如何工作的，或者对它进行破解，但是有一些工具可以在应用程序上使用，以防止出现这种情况。或者至少让它变得更困难，对吧。但与其创建WCF服务，不如将其在程序集中分离。您可以使用WCF，因为您希望在不同的层中分发您的客户机和服务器，但无论如何，WCF是门户，您需要在程序集中预先分离类，这样您就可以通过服务端点公开您的业务，并通过客户机使用它们。我相信，即使在小项目中，以一种好的方式组织代码也不会耗费时间。这是一个很好的实践，可以在维护和分发代码库方面节省时间。我最感兴趣的是这个答案的后半部分。好吧，我试着介绍了许多关于在程序集中拆分的内容：）很高兴知道这正是您需要的。