2

不必要な肥大化を招くことなく、ビジネスプロジェクト間で簡単に移植できるように、コードをどのように編成しますか？

たとえば（.Netの場合）、次の名前空間があるとします。

namespace Computers
    - Hardware
         - Motherboard
         - GPU
namespace Monitors
    - Display
         - Mirrors
namespace Peripherals
    - USB
    - PS/2
  • 親名前空間ごとにプロジェクトを作成してから、そのプロジェクトdllを他のプロジェクトで参照しますか？
  • 1つの大きなクラスのライブラリを作成し、それを移植しますか（ライブラリの5％しか必要ない場合でも）？
  • または、1つのファイルを作成し、必要なコードをそのファイルにコピーしますか。そのファイルを、「プラグアンドプレイ」アーキテクチャを実現するために必要なすべてのプロジェクトに取り込んでいますか？

編集： 私は具体的に.Netの回答を探していませんが、それは私が使用している具体的な例です（抽象的な例ではこの場合の質問を理解するのが難しくなるため）

4

6 に答える 6

0

私は単一のdllから始めますが、それが大きくなり、かなり独立したコンポーネントが含まれるようになると、それらを個別のdllとして除外することを選択できます。私にとって、それは主に美学の問題です-私は物事を独立させ、直交させ、よく組織化しておくのが好きです。現在利用可能なメモリとディスクスペースの量を考えると、1つの大きなdllに問題はありません。

于 2009-08-08T17:54:33.013 に答える
0

複数のプロジェクトで共有されるものについては、通常、1 つの大きな DLL アプローチを使用します。ただし、この男を使用するプロジェクトが多数ある場合は、強力な名前を付けて GAC に放り込むことを強くお勧めします。より多くのプロジェクトを追加するにつれて、最終的に遭遇するのは、共有コンポーネントに破壊的な変更を加えたいという欲求です。厳密な名前付け/GAC を使用していない場合は、変更を行うたびにすべてのアプリを更新する必要があり、必然的に 1 つを忘れてしまい、本番環境で何かが爆発します。

厳密な名前を付けて、ソース管理の集中フォルダーにリリース バージョンを保持し、常にそれを参照します。次に、展開時にGACに投げます。

于 2009-08-12T04:40:28.553 に答える