2

大規模なJava/.Net Enterpriseプロジェクトでは、すべての開発者がビルドするために、クラスパス/ローカル開発環境にすべてのコンポーネント/ライブラリ/依存関係を持っている必要がありますか？

または、それらを小さなセクションに分割して、個別に構築することができますか（すべての依存関係を参照する必要がないように）？

つまり、アプリケーション全体を実行する場合は、すべてのコンポーネントが必要です。ただし、アプリのサブセットのみを実行している場合は、対応するコンポーネントのサブセットのみが必要になります。

大企業プロジェクトは通常、最初の方法で編成されていますか、それとも2番目の方法で編成されていますか？

考えられる編成は、自己完結型であるが他のモジュールによって参照されているプロジェクト全体のモジュール（つまり、依存関係ツリーのリーフノード）で作業している場合です。

もう1つの構成は、使用するクラスを動的にロードする場合、クラスパスにクラスを含めずにビルドできることです。それを実行するには、クラスパスは実際にロードしたものにアクセスするだけで済みます（プロジェクトのさまざまな部分を形成し、ロードしないものが他にもたくさんある場合があります）。

これらは理論上の可能性です。しかし、実際には、エンタープライズプロジェクトの標準的な方法は何ですか？

同じ問題がそこで発生すると思うので、これを.Netを含むように拡張しました（DLL地獄？）

4

6 に答える 6

4

この質問に対する答えは、プロジェクトごとに異なります。いくつかの一般的なポイント：

  • 「アプリのサブセットを実行する」ことは、多くの場合不可能です。モジュール化されているため、各部分が実際に独立して実行できるアプリはほとんどないためです。
  • 時々持っているのは、常に必要なアプリコアと、そのコア上に構築された、多かれ少なかれ互いに独立しているモジュールです。
  • 大きな違いは、通常、すべてのコンポーネントを持っているかどうかではなく、ソースコードとして持っているかJARファイルとして持っているかです。
  • 大規模なアプリでは、開発者は通常、作業中の部分のみをソースコードに、残りはJARファイルとして使用します。
  • 実行時のモジュール化が必要な場合（つまり、コンポーネントは実行時にオンデマンドでロードおよびアンロードされる）、それがOSGiの目的です。
于 2009-08-22T13:08:48.727 に答える
2

構築するサブセットとテストを実行するサブセットだけが必要な場合もありますが、サイズが自明ではないJavaプロジェクトのすべての依存関係は、追跡するのに非常にすぐに悪夢になる可能性があるため、Java開発者は開発を愛するようになりました。愛/憎しみ-開発環境を管理するMavenなどの精巧なビルドシステムとの関係。

このようなシステムを使用しないプロジェクトの場合、通常、常にすべてを含めるのが最も簡単です。トレードオフは、開発環境が不必要に肥大化することと、欠落している依存関係を追跡するために時間を費やす必要があることです。

于 2009-08-22T12:30:28.670 に答える
1

優れたプロジェクト構造は、独立したモジュールを実行できるように物事を分解します。

しかし、実際には、私が見たほとんどのプロジェクトは、誰かがうんざりして、主導権を握ってそれらを分解するまで、これを行いません。

MavenやIvyなどの優れた依存関係管理インフラストラクチャを適切に使用している場合は、コンパイル済みモジュールをサーバーに保存し、必要に応じてこれらの依存関係をダウンロードできます。

また、他の製品コンポーネントへのテストの依存関係を分析するのに役立つ多くのモックオブジェクトとサービスを用意することもできます。

于 2009-08-22T13:03:15.497 に答える
1

私は確かに、物事を分離することは「良い」だろうというコメントに同意します。しかし実際には、それは非常にまれです。

分離されていない環境で作業しなければならないと仮定すると、別の組織戦略があり、それが私が使用しているのを見てきました。あなたの質問はビルドと実行の両方の依存関係に言及しているので、プロセスについてではなく、クラスとjarについて話しているように見えます。

そのための簡単な解決策は、構築され、統合テストされた（または、さらに言えば、統合テスト対応の）依存関係の完全なセットを共有サーバー上に置くことです。

次に、開発者は、最初に開発を参照し、次に適切な共有サーバーを参照するクラスパスを使用して、作業しているシステムの部分をローカル環境で構築します。

于 2009-08-22T13:32:04.030 に答える
0

あなたの質問はあまり明確ではありませんが、答えは、アプリケーションが必要とするすべてのクラスがCLASSPATHにあるか、ClassNotFoundExceptionをスローするクラスローダーにある必要があるということだと思います。

それは、あなたが単独の開発者であろうと、より大規模な分散チームで働いていようと、真実です。

私の経験では、アプリケーションは一方向にパッケージ化されています。サブセットのみが必要な場合は、そのようにパッケージ化する必要があります。

テストケースを別のものとして意味する場合、それらは通常、製品コードと一緒にパッケージ化されていません。

于 2009-08-22T12:30:11.650 に答える
0

私の意見では、開発者がアプリケーションのサブセットで作業できるかどうかではなく、アプリを構成するプロジェクト（Eclipseプロジェクトを考えてください）間の依存関係を管理することができます。多くの場合、1つ以上のプロジェクトが他のプロジェクトに依存できるようなプロジェクトのツリーがある場合があります。このような場合、通常、このアップストリームプロジェクトの変更によってダウンストリームプロジェクトが破損しないようにするのは、アップストリーム/共通プロジェクトの役割です。

このように考えてください-アプリケーションのすべての共通/ユーティリティ機能を配置するプロジェクトがあると仮定しますutils-これは検証ロジック、文字列ユーティリティ、ロギングなどです。そして、からのクラスを使用する他のプロジェクトがたくさんありますこれutils。

    utils
   /     \
proja   projb

この場合、作業者は開発環境も持っているutils 必要がproja あり projbます。変更を加えると、開発環境utilsが壊れる可能性があります。ただし、作業しているだけの場合は、そのプロジェクトに依存していないprojbため、含める必要がない場合があります。proja

于 2009-08-22T14:48:33.273 に答える