代码之家  ›  专栏  ›  技术社区  ›  John Sheehan

内部.NET应用程序是否应与它们所依赖的内部库放在同一命名空间中?

  •  0
  • John Sheehan  · 技术社区  · 6 年前

    我工作的公司最近决定使用.NET和Java的组合来进行未来的开发工作。我们一直试图规范我们如何将代码组织到命名空间(.NET)和包(Java)中,没有人真的有经验来组织涉及多个平台的多个产品的命名空间。

    最近,我参与了一个新的产品,它使用一个Java前端(它在黑莓设备上运行),带有.NET后端(一个消息代理,它允许Java前端与我们遗留的VB6/COM代码通信,因为我们不想在Java端处理COM,而且很容易制作.NET。使用我们现有的vb6代码)。现在我只关注.net方面的事情。

    我创建了一个名为 CompanyName.ProductName.Broker ,最终得到两个子项目:a Core 实现大部分代理代码的类库项目,以及 BrokerConsole 允许代理从命令行启动和停止的控制台项目(代理将与rabbitmq消息队列服务器一起在服务器上运行)。

    现在,两个项目都在 公司名称.productname.broker 命名空间。问题是,这有意义吗?

    一方面, 断线孔 项目与 核心 但另一方面 断线孔 编译为独立的exe。我在想,把它放进去可能会更有意义。 断线孔 投影到一个单独的根命名空间中,可能类似于 CompanyName.Apps.ProductName ,因为它实际上是 CompanyName.ProductName.Broker.Core.dll 是一个应用程序,而不是一个库。

    我创造一个全新的 CompanyName.Apps 根命名空间是指,通常在创建应用程序时,将其放在与所引用的库不同的命名空间中(即,不会将web服务器应用程序放在 System.Web 命名空间)。我也是这么想的,只是引用的库碰巧是公司开发的库。

    这是一个好主意,还是我应该试着把与“产品”(在市场营销术语中)相关的一切都放在 CompanyName.ProductName 命名空间?有没有更好的方法来管理由一个产品组成的多个项目?

    5 回复  |  直到 15 年前
        1
  •  2
  •   SergioL    15 年前

    我通常将可执行应用程序划分到它们自己的名称空间中。据我所知,名称空间有助于代码组织,所以我认为很少有人会从另一个项目引用brokerconsole应用程序。

    所以,基本上,我会创造:

    • 公司名称.productname.broker.core
    • 断线孔
        2
  •  1
  •   Jon Skeet    15 年前

    我会将两者分为companyname.productname.broker.console和companyname.productname.broker.core。考虑到system.console的存在,惟一的潜在问题是使用console作为名称。(这可以避免使用CuffyNAM.StudioNo.Boo.BooCudio,但这有点难看。)

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

        3
  •  1
  •   Fredrik Mörk    15 年前

    我认为你的方法是有道理的,而且它遵循的逻辑与我通常遵循的基本相同,而且在我目前的客户(一家相当大的公司)中也是如此。

    我想,如果我给出的名字是:汇编 CompanyName.ProductName.Broker.Core 很可能 CompanyName.ProductName.Broker 作为其“顶级”命名空间(不包括 Core ,而控制台应用程序(我将命名为 CompanyName.ProductName.Broker.Console ;命名空间已经建立了代理部分)将在程序集名称和命名空间名称之间具有一对一关系。

    我认为将控制台与库分离是没有意义的,因为将它放在一个完全独立的名称空间中,恰恰相反。我认为他们 应该 因为它们是同一个产品的一部分,所以要住在同一个名称空间中。

        4
  •  1
  •   Shiraz Bhaiji    15 年前

    我们通常将其拆分,以便解决方案中的每个项目都有自己的名称空间,在每个项目中可能有子名称空间。每个项目,因此每个名称空间都包含在它自己的dll中。

        5
  •  0
  •   LBushkin    15 年前

    我通常使用名称空间来划分一个类与其他类在责任和相互依赖方面的关系,有时也会使用意图。

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

    根据您的描述,我认为您对程序集的物理分离是有意义的,因为它提供了重用和替换的机会。

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

    例如,我可能有一个companyname.productname.utility命名空间,两个程序集都使用它来组织实用程序代码,即使程序集之间没有共享。

    推荐文章