我工作的公司最近决定使用.NET和Java的组合来进行所有未来的开发工作。我们一直在努力标准化我们如何将代码组织成命名空间（.NET）和包（Java），并且没有人真正尝试为涉及多个平台的多个产品组织命名空间。
最近，我参与了一个新产品，它使用了一个带有.NET后端的Java前端（它在Blackberry设备上运行）（一个允许Java前端与我们的传统VB6 / COM代码通信的消息代理，因为我们我不想在Java方面处理COM，并且很容易使.NET与我们现有的VB6代码一起工作）。现在我只关注.NET的一面。
我创建了一个名为CompanyName.ProductName.Broker的新.NET解决方案，最终得到了两个子项目：实现大部分代理代码的Core类库项目和BrokerConsole控制台允许代理从命令行启动和停止的项目（代理将与RabbitMQ消息队列服务器一起在服务器上运行）。
现在，两个项目都在CompanyName.ProductName.Broker命名空间的子名称空间中。问题是，这有意义吗？
一方面，BrokerConsole项目与Core项目紧密耦合，但另一方面，BrokerConsole编译为独立的EXE。我认为将BrokerConsole项目放入单独的根命名空间可能更有意义，可能类似于CompanyName.Apps.ProductName，因为它实际上是CompanyName.ProductName.Broker.Core.dll的前端，并且是一个应用程序反对图书馆。
创建全新CompanyName.Apps根命名空间的基本原理是，通常在创建应用程序时，将其放入与您引用的库中不同的命名空间（即，您不会放置Web服务器）应用程序进入System.Web命名空间）。我正在考虑相同的思路，除了引用的库恰好是公司开发的库。
这是一个好主意，还是应该尝试将所有与“产品”（在营销方面）相关的内容保存在一个共同的CompanyName.ProductName命名空间下？是否有更好的方法来管理组成单个产品的多个项目？
答案 0 :(得分：2)
我传统上将可执行应用程序分解为自己的命名空间。根据我的理解，命名空间可以帮助解决代码组织问题，所以我认为很少有人会从另一个项目中引用BrokerConsole应用程序。
所以，基本上，我会创建：
答案 1 :(得分：1)
我会将两者分成CompanyName.ProductName.Broker.Console和CompanyName.ProductName.Broker.Core。考虑到System.Console的存在，唯一可能的问题是使用Console作为名称。 （使用CompanyName.ProductName.Broker.BrokerConsole可以避免这种情况，但这有点难看。）
将两者分开将使未来可能还想使用核心功能的应用更加清晰。
答案 2 :(得分：1)
我认为你的方法是有道理的，它遵循我通常遵循的几乎相同的逻辑，并且在我当前的客户（一个相当大的公司）也遵循。
我认为，如果我提供名称，差异可能就是这样：汇编CompanyName.ProductName.Broker.Core很可能将CompanyName.ProductName.Broker作为其“顶级”命名空间（不包括单词Core虽然Console应用程序（我将命名为CompanyName.ProductName.Broker.Console;命名空间已经建立了Broker部分），但程序集名称和命名空间名称之间将存在一对一的关系。
我认为将控制台与库分开放在一个完全独立的命名空间中是没有意义的，恰恰相反。我认为他们应该存在于同一名称空间中，因为它们是同一产品的一部分。
答案 3 :(得分：1)
我们通常将其拆分，以便解决方案中的每个项目都有自己的命名空间，在每个项目中可能有子命名空间。每个项目，因此每个命名空间都包含在它自己的dll中。
答案 4 :(得分：0)
我通常使用命名空间作为一种方式来分类一个类在责任和相互依赖性方面与其他类的关系 - 偶尔也是意图。
我使用程序集根据类是否分布在一起以及功能是否位于同一位来对类进行分区。我还使用程序集来分区系统的元素，这些元素可以独立部署，由多个项目使用，也可以在生产中替换或替换。
根据您的描述，我认为您的组件物理分离是有意义的，因为它提供了重用和替换的机会。
但是，如果类的意图相似或存在逻辑依赖关系，我可能会选择在程序集之间共享一些名称空间。例如，我可能有一个CompanyName.ProductName.Utility命名空间，两个程序集都用它来组织实用程序代码 - 即使程序集之间没有共享它。