有关分区程序集和命名空间的策略提示

Question

对于技术架构师来说，一个非常常见的复杂性是将应用程序划分为程序集和名称空间。

• 程序集可以根据部署、性能和安全边界进行分区。
• 命名空间可以根据逻辑应用程序边界进行分区。

另外:命名空间可以跨越多个程序集。

有一次，在一个项目中，我们根据应用程序的逻辑单元对程序集进行分区，我的经验很糟糕。这个决定最终得到了30或40个项目的解决方案文件！主解决方案文件加载时间约为。5分钟！这最后是浪费时间，笨蛋.

相反的情况是，当真正需要时，将所有代码保存在1程序集和分区中。

您有关于这个问题的其他提示或最佳实践吗？

Answer 1

只有当我需要将代码重用到两个不同的应用程序时(差不多)，我才将代码分割成单独的程序集。因此，我从一个项目中的所有东西开始，当重用代码的需求变得明显时，我创建一个新的程序集并移动代码(有时从一开始就很明显，例如，当您需要一个web应用程序并赢得表单做同样的事情时)。

Re.名称空间，我更喜欢在程序集中很好地分区它，因此可以清楚地知道每个类属于哪里以及它应该用于什么。

Answer 2

为了便于维护，您可以使用名称空间对类进行分区，并使用文件夹(如果希望将源文件分组)。如果您有安全要求，并且某些程序集需要经过特殊处理，例如混淆，那么您可能需要将这些处理分离到单独的项目中。

在考虑一个逻辑单元是否需要得到自己的项目时，可重用性也是一个需要考虑的因素，因为您可能也需要在另一个解决方案中使用这个项目。

Answer 3

对我来说效果很好的是按代码类型进行大级别分组，但宏级别要比您所划分的逻辑单元更大。例如,

• 引擎-任何非视觉的东西。支持类、基本基础结构代码。每件事都是指这个。
• EngineUI -依赖引擎，显然用于用户界面，但没有任何一个应用程序的特定用途。
• EngineServer -依赖于引擎，用于(通常是web)服务器构建。
• AppCore -应用程序特定的核心功能，没有UI。
• AppUI -应用程序专用UI
• AppClient -使用AppUI，AppCore，EngineUI，Engine。真正的客户端应用。
• AppServer -使用AppServer，EngineServer，Engine。服务器应用程序。

每个项目都有一个名称空间的层次结构，偶尔我会发现将大量代码发送到另一个程序集中是很有用的，但通常这些代码会保持合理的组织和可管理性，即使涉及到数百个文件。太多的项目绝对是我想要避免的。将这些项目保持在最低限度的好处之一是，它使实际在后续项目中重用这些库(例如自动测试构建)变得更加容易。

我不太担心从这些库中部署未使用的代码，因为我可以使用一个实用程序，将未使用的函数排除在最后的构建中，将文件大小降到最低。