開発プロジェクト (ASP.NET MVC アプリケーションなど) を複数のプロジェクトに分割する一般的な理由は何ですか? コードの整理は、フォルダーを介して行うこともできます。複数のプロジェクトは、循環参照の競合を生成し、それらを管理/解決する必要があるため、複雑さを増す傾向があります。
なぜ？
質問する
3420 次
8 に答える
7
いくつかの理由は
カプセル化 - 一連のルーチンをスタティック ライブラリまたは一連の dll として別のライブラリにパッケージ化することにより、ブラック ボックスになります。優れたブラック ボックスであるために必要なことは、適切な入力を与え、適切な出力を得ることだけです。そのライブラリを再利用するときに役立ちます。また、特定のルールを適用し、ハッキングによるプログラミングを防ぎます (「うーん...とりあえず、そのメンバー関数を公開します」)。
コンパイル時間を短縮 - ライブラリは既にコンパイルされています。コンパイル時に再構築する必要はなく、リンクするだけです (C++ を使用している場合)。
デカップリング - クラスをスタンドアロン ライブラリにカプセル化することで、結合を減らし、ライブラリを他の目的に再利用できます。同様に、ライブラリのインターフェイスが変更されない限り、ライブラリに好きなように変更を加えることができ、ライブラリにリンクまたは参照する他のユーザーは、コードをまったく変更する必要はありません。DLL は、再コンパイルが不要な点で便利ですが、多くのアプリケーションが同じ DLL の異なるバージョンをインストールする場合、操作が難しくなる可能性があります。クライアントのコードに影響を与えずにライブラリを更新できます。フォルダだけでも同じことができますが、この動作を強制する明示的なメカニズムはありません。
また、さまざまなライブラリを使用するという規律を実践することで、記述した内容が汎用的であり、実装から切り離されていることを確認することもできます。
ライセンス/商品化 - ええと、これは非常に明白だと思います。
于 2009-08-24T05:17:27.523 に答える
3
1 つの可能性は、特定のグループ (または 1 人の開発者) が残りのコードから独立して作業できるシステムを持つことです。もう 1 つは、システムの残りの部分が必要とする共通のユーティリティ コードを除外することです。たとえば、エラー処理、ログ、共通のユーティリティなどが思い浮かびます。
もちろん、特定の関数/クラス/ファイルに何が入るかを考えるとき、境界がどこにあるかは科学ではなく芸術の問題です。
于 2009-08-24T04:54:11.500 に答える
1
私が考えることができる 1 つの例は、1 つのプロジェクトを開発しているときに、より一般的に使用され、独自のプロジェクトに値するライブラリを開発することになる場合があるということです。たとえば、ビデオ ゲームに取り組んでいて、そのゲーム プロジェクトとはまったく関係のないオーディオ ライブラリを作成することになったとします。
于 2009-08-24T04:56:17.363 に答える
1
コードの再利用。プロジェクト A があり、プロジェクト A と同じ機能の多くを持つ新しいプロジェクト B を開始するとします。A の共有部分を引き出して、A と B の両方で使用できるライブラリにするのは理にかなっています。 . これにより、2 つの場所で同じコードを維持する必要なく、両方にコードを含めることができます。
コードの再利用、反転。1 つのプラットフォームで動作するプロジェクトがあるとします。次に、2 つのプラットフォームで動作するようにします。プラットフォームに依存するコードを分離できる場合は、プラットフォームに依存するライブラリごとに異なるプロジェクトを開始し、プラットフォームごとに異なるライブラリを使用して中央のコードベースをコンパイルできます。
于 2009-08-24T05:43:26.440 に答える
0
ここにはいくつかの良い答えがあるので、繰り返さないようにします。
コードを独自のプロジェクトに分割する利点の 1 つは、アセンブリを複数のアプリケーションで再利用できることです。
言及された機能的アプローチも気に入りました (たとえば、在庫、配送などはすべて独自のプロジェクトを取得できます)。もう 1 つのアイデアは、展開モデルを検討することです。レイヤー、層、またはサーバー間で共有されるコードは、おそらく独自の共通プロジェクト (または、より細かい制御が必要な場合はプロジェクトのセット) にある必要があります。特定の層に割り当てられたコードは、それ自体のプロジェクトにある場合があります。たとえば、別の Web サーバーとアプリケーション サーバーがある場合、UI コードをアプリケーション サーバーにデプロイする必要はありません。
分割するもう 1 つの理由は、アプリケーションが本番環境に入った後で、小規模な増分デプロイを許可することです。修正が必要な緊急の本番環境のバグが発生したとします。小さな変更で (1 つのプロジェクトの) アプリケーション全体の再構築が必要な場合、小さなテスト サイクルを QA に正当化するのに苦労する可能性があります。より小さな機能セットを備えたアセンブリを 1 つだけ展開する場合は、販売が容易になる可能性があります。
于 2009-08-24T07:48:32.337 に答える
0
1 つのものに対する所有権。コード ベースのさまざまな部分を担当する開発者がいる場合、プロジェクトを分割するのは当然のことです。プロジェクトを機能別に分割することもできます。これにより、競合と複雑さが軽減されます。それが増加する場合、それは単にコミュニケーションの欠如を意味し、あなたのやり方が間違っているだけです.
于 2009-08-24T04:54:40.533 に答える
0
複数のアセンブリ内のコードの価値を疑問視する代わりに、すべてのコードを 1 か所にまとめることの価値を疑問視してください。
キッチンにあるすべてのものを 1 つのキャビネットに収納しますか?
循環参照は、アセンブリ間またはアセンブリ内で発生するかどうかにかかわらず、循環参照です。問題のあるコンポーネントの設計は、おそらく最適ではありません。皮肉なことに、アセンブリを介した編成を避けると、コンパイラが状況を検出できなくなります。
プロジェクトと同じようにフォルダーでもコードを整理できるという記述が理解できません。もしそうなら、私たちのオペレーティング システムには個別のドライブという概念がありません。1 つの巨大なフォルダー構造を持つだけです。高次の組織パターンは、単純なフォルダーとは異なる種類の意図を表しています。
プロジェクトは、「これらの概念は密接に関連しており、他の概念とは周辺的にのみ関連している」と述べています。
于 2009-08-24T05:45:16.907 に答える