0

我工作的公司最近决定将 .NET 和 Java 结合用于所有未来的开发工作。我们一直在尝试标准化将代码组织到命名空间 (.NET) 和包 (Java) 中的方式，并且没有人真正有尝试为涉及多个平台的多个产品组织命名空间的经验。

最近，我参与了一个使用 Java 前端（在黑莓设备上运行）和 .NET 后端（允许 Java 前端与我们的旧版 VB6/COM 代码通信的消息代理）的新产品，因为我们没有想要在 Java 端处理 COM，并且很容易使 .NET 与我们现有的 VB6 代码一起工作）。现在我只关注.NET 方面的事情。

我创建了一个新的.NET 解决方案，CompanyName.ProductName.Broker名为与 RabbitMQ 消息队列服务器一起在服务器上）。CoreBrokerConsole

现在，这两个项目都在命名空间的子CompanyName.ProductName.Broker命名空间中。问题是，这有意义吗？

一方面，该BrokerConsole项目与项目非常紧密耦合Core，但另一方面，该项目BrokerConsole编译为独立的 EXE。我认为将项目放入单独的根命名空间可能更有意义BrokerConsole，可能类似于CompanyName.Apps.ProductName，因为它实际上是一个前端CompanyName.ProductName.Broker.Core.dll并且是一个应用程序而不是一个库。

我创建一个全新的CompanyName.Apps根命名空间的理由是，通常当您创建应用程序时，您将其放入与您所引用的库不同的命名空间中（即您不会将 Web 服务器应用程序放入System.Web命名空间中）。我的想法是一样的，只是引用的库恰好是公司开发的库。

这是一个好主意，还是我应该尝试将与“产品”（营销术语）相关的所有内容保存在一个公共CompanyName.ProductName命名空间下？是否有更好的方法来管理共同构成一个产品的多个项目？

4

5 回答 5

2

传统上，我将可执行应用程序分解为它们自己的名称空间。据我了解，命名空间有助于代码组织，所以我认为很少有人会从另一个项目中引用 BrokerConsole 应用程序。

所以，基本上，我会创建：

  • CompanyName.ProductName.Broker.Core
  • 经纪人控制台
于 2009-07-15T17:48:39.567 回答
1

我会将两者分成 CompanyName.ProductName.Broker.Console 和 CompanyName.ProductName.Broker.Core。考虑到 System.Console 的存在，唯一的潜在问题是使用 Console 作为名称。（使用 CompanyName.ProductName.Broker.BrokerConsole 可以避免这种情况，但这有点难看。）

将两者分开将使未来可能也希望使用核心功能的应用程序更加清晰。

于 2009-07-15T17:42:09.407 回答
1

我认为您的方法是有道理的，它遵循与我通常遵循的几乎相同的逻辑，并且我当前的客户（一家相当大的公司）也遵循这一逻辑。

我认为，如果我给出名称，差异可能是这样的：程序集CompanyName.ProductName.Broker.Core很可能具有CompanyName.ProductName.Broker其“顶级”命名空间（不包括单词Core），而控制台应用程序（我将命名CompanyName.ProductName.Broker.Console；命名空间已经建立Broker 部分）将在程序集名称和命名空间名称之间具有一对一的关系。

我认为将控制台与库分开放置在一个完全独立的命名空间中是没有意义的，恰恰相反。我认为它们应该存在于同一个命名空间中，因为它们是同一个产品的一部分。

于 2009-07-15T17:44:37.530 回答
1

We normally split it up so that each project within a solution has it's own namespace, within each project there may be sub-namespaces. Each project, and therefore each namespace is therefore contained in it's own dll.

于 2009-07-15T17:50:04.523 回答
0

我通常使用命名空间作为划分一个类与其他类在责任和相互依赖方面的关系的一种方式 - 偶尔还有意图。

我使用程序集根据类是否分布在一起以及功能是否位于同一位置来划分类。我还使用程序集来划分系统的元素，这些元素要么独立部署，要么被多个项目使用，要么可以在生产中被替换或替换。

根据您的描述，我认为您对组件的物理分离是有道理的，因为它提供了重用和替换的机会。

但是，如果类的意图相似或存在逻辑依赖关系，我可能会选择在程序集之间共享一些命名空间。

例如，我可能有一个 CompanyName.ProductName.Utility 命名空间，两个程序集都使用它来组织实用程序代码——即使它不在程序集之间共享。

于 2009-07-15T18:31:47.840 回答