14

次のような構造を使用する大規模なアプリケーション（〜50モジュール）があります。

  • 応用
    • 通信モジュール
      • カラー通信モジュール
      • SSN通信モジュール
      • 等通信モジュール
    • ルーターモジュール
    • サービスモジュール
      • 投票サービスモジュール
        • 投票用のWebインターフェイスサブモジュール
        • 投票用の投票コレクターサブモジュール
        • 投票など
      • クイズサービスモジュール
      • などモジュール

アプリケーションをMavenとSubversionにインポートしたいと思います。いくつかの調査の結果、これには2つの実用的なアプローチが存在することがわかりました。

1つは、前のものと同じようにツリー構造を使用しています。この構造の欠点は、マルチモジュールレポートをMavenでうまく機能させるために、大量の調整/ハックが必要になることです。もう1つの欠点は、Subversionでは、標準のトランク/タグ/ブランチのアプローチにより、リポジトリがさらに複雑になることです。

もう1つのアプローチは、フラット構造を使用します。この場合、親プロジェクトは1つだけで、すべてのモジュール、サブモジュール、およびサブモジュールの一部が親プロジェクトの直接の子になります。このアプローチはレポート作成に適していて、Subversionの方が簡単ですが、この方法では構造が少し失われているように感じます。

長期的にはどちらの方法を選びますか、またその理由は何ですか。

4

2 に答える 2

15

私たちは大規模なアプリケーション (各バンドルが Maven モジュールである 160 以上の OSGi バンドル) を持っています。階層内のセマンティクスをエンコードする際の問題は、柔軟性が失われることです。今日は 100% 「通信」であるモジュールが、明日には部分的に「サービス」になる可能性があります。その場合、リポジトリ内で物事を移動する必要があり、あらゆる種類のスクリプト、ドキュメント、リファレンスなどを壊してしまいます。

したがって、フラットな構造をお勧めし、セマンティクスを別の場所 (たとえば、IDE ワークスペースやドキュメントなど) にエンコードすることをお勧めします。

バージョン管理レイアウトに関する質問に、別の質問で例を挙げて詳細に回答しました。状況に関連している可能性があります。

于 2008-08-21T18:07:00.513 に答える
3

ディレクトリ構造をフラットにしたほうがいいと思います。おそらく、すべてのプロジェクトを表示するときにディレクトリが適切にソートされるように、ディレクトリの命名規則を考え出す必要がありますが、最終的には、その余分な階層のすべてが必要だとは思いません.

IDE として Eclipse を使用していると仮定すると、プロジェクトをインポートすると、すべてのプロジェクトがフラットなリストになってしまうため、追加のサブディレクトリから実際には何も得られません。余分な階層がなくても構成が非常に単純であるという事実に加えて、私の頭の中では選択がかなり明確になります。

また、いくつかのモジュールを組み合わせることを検討することもできます。あなたのアプリやドメインについては何も知りませんが、これらのリーフ レベル モジュールの多くは、別のトップ レベル モジュール内の単なるパッケージまたはパッケージのセットとして適しているようです。私はジャーをまとまりのあるものに保つことに賛成ですが、時には行き過ぎてしまうこともあります。

于 2008-08-21T18:06:52.073 に答える