14

我有一个使用类似于以下结构的大型应用程序（约 50 个模块）：

  • 应用
    • 通讯模块
      • 彩色通讯模块
      • SSN通讯模块
      • 等通讯模块
    • 路由器模块
    • 服务模块
      • 投票服务模块
        • 用于投票的 Web 界面子模块
        • 用于投票的投票收集器子模块
        • 投票等
      • 测验服务模块
      • 等模块

我想将应用程序导入 Maven 和 Subversion。经过一些研究，我发现为此存在两种实用的方法。

一种是使用与前一种相同的树结构。这种结构的缺点是您需要大量的调整/修改才能使多模块报告与 Maven 一起工作。另一个缺点是在 Subversion 中，标准的 trunk/tags/branches 方法给存储库增加了更多的复杂性。

另一种方法使用扁平结构，其中只有一个父项目，所有模块、子模块和部分子模块都是父项目的直接子项目。这种方法适用于报告，并且在 Subversion 中更容易，但是我觉得这样我失去了一些结构。

从长远来看，您会选择哪种方式，为什么？

4

2 回答 2

15

我们有一个较大的应用程序（160 多个 OSGi 包，其中每个包都是一个 Maven 模块），我们学到并继续学习的教训是扁平化更好。在你的层次结构中编码语义的问题是你失去了灵活性。一个今天 100% 说“通信”的模块明天可能部分是“服务”，然后你需要在你的存储库中移动东西，这将破坏各种脚本、文档、参考等。

所以我会推荐一个平面结构并在另一个地方对语义进行编码（比如一个 IDE 工作区或文档）。

我已经通过另一个问题的示例详细回答了一个关于版本控制布局的问题，它可能与您的情况有关。

于 2008-08-21T18:07:00.513 回答
3

我认为你最好扁平化你的目录结构。也许您想为目录提出一个命名约定，以便在查看所有项目时很好地排序，但最终我认为所有这些额外的层次结构都是不必要的。

假设您使用 Eclipse 作为您的 IDE，一旦您导入它们，所有项目最终都将出现在一个平面列表中，因此您实际上不会从其他子目录中获得任何东西。除了没有所有额外层次结构的配置非常简单的事实之外，这让我的选择非常清楚。

您可能还想考虑组合一些模块。我对您的应用程序或域一无所知，但似乎很多叶级模块可能更适合作为另一个顶级模块中的包或包集。我完全赞成保持罐子的凝聚力，但有时可能会走得太远。

于 2008-08-21T18:06:52.073 回答