1

設計パターン (例: Visitor)、SOLID (Single Responsibility など)、KISS (Keep it Simple、Stupid)、階層型設計などについて説明しているドキュメントはたくさんあります。

私が完全に理解していないことの 1 つは、アプリケーションを拡張するときに新しいプロジェクト/DLL がいつ必要になるかを決定する方法です。使用される基準はありますか？

たとえば、System.Windows.Forms (http://msdn.microsoft.com/en-us/library/system.windows.forms.containercontrol.aspx) は System.Windows.Forms.dll の一部ですが、System から派生しています。 mscorlib.dll の一部である .MarshalByRefObject。

4

2 に答える 2

4

アセンブリ（DLL）と名前空間を混同しています。

アセンブリは、クラスなどの実装を含むバイナリファイルです。

名前空間は、クラスや列挙型などを論理グループに編成し、すべてのレベルからすべてのクラスにアクセスできないようにし、名前の競合（System.Windows.Forms.TimerおよびなどSystem.Threading.Timer）を防ぐための単なる方法です。

System.Windows.Formsから派生したものではなく、mscorlib.dllだけに存在するわけSystemでもありません。System誰でもSystem名前空間に何でも入れることができます-あなたがそれをすることさえできます。これは、のサブ名前空間にすぎませんSystem。

コードのサブセットを別のアセンブリに分割する理由はいくつかあります。大きな問題は再利用性です。いくつかの共通のコントロールまたはユーティリティがある場合は、それを独自のDLLに保持し、コードをコピーして貼り付けることなくプロジェクト全体で使用できます。

于 2012-12-28T19:14:47.560 に答える
1

ティアとレイヤーを混同しないでください。コードをレイヤー化することは、ほとんどの場合必須です。ただし、コードを別々の物理層に分割することは、通常、実際に必要になるまで実行したくないことです (KISS の原則に従います)。

コードを適切に階層化すると、コードを別々の層に分割する必要が生じたときに、非常に簡単なプロセスになるはずです。ただし、コードを適切に階層化したことがない場合は、階層を分割するのが非常に難しいことに気付くでしょう。

簡単な例として、ログイン フォームを作成し、システム情報を収集し、データベースにアクセスし、ユーザー資格情報を検証し、アクセス許可を構築するためのすべてのロジックをすべて WinForm クラスに直接配置するとします。今説明したコードには 1 つの層しかなく、1 つの層しかありません。その後、ASP.NET を使用して Web ベースのログイン ページを作成する必要が生じた場合、その既存のコードを再利用するのは非常に困難です。Web ベースのログインでは、少なくとも UI ロジックをビジネス/データ アクセス ロジックから分離する必要がありますが、すべて直接 WinForm クラスにあるため、コードをリファクタリングしないとすべて使用できません。

ここで、すべてのコードをフォームに配置する代わりに、時間をかけて適切にレイヤー化したとしましょう。データベースにアクセスするすべてのコードを分解して、すべてをデータ アクセス クラスに入れたとします。そして、すべてのビジネス ロジック コードをビジネス クラスに配置します。その時点で、WinForm クラスの実際のコードは、コントロール イベントの処理、ラベルの設定など、UI 関連のロジック以外には何も実行しないように制限する必要があります。この 2 番目の例では。まだ 1 つの層しかありませんが、3 つの別個の独立した層 (つまり、UI、ビジネス、データ アクセス) があります。

既にそのようなコードを階層化している場合は、Web ベースのプロジェクトで再利用する必要が生じたときに、ビジネス レイヤーとデータ アクセス レイヤーをクラス ライブラリ (dll) に簡単に移動して、サーバー側層の ASP.NET プロジェクト。

コードを個別のクラス ライブラリに分割する必要があるのは、通常、次の 2 つの状況だけです。

  1. 複数のプロジェクトでコードを再利用する必要がある
  2. プロジェクトを複数の層に分割する必要がある

すべてのコードを 1 つのプロジェクトに入れても、階層化されていれば、そのような状況が発生したときにプロジェクトを複数のクラス ライブラリに分割するのは非常に簡単です。したがって、大きな設計上の問題は、DLL の数ではありません。むしろ、大きな設計上の問題は、レイヤーの数です。コードを階層化すると、必要に応じて異なるプロジェクト間でコードを簡単に移動できます。

実際には、プロジェクト間でコードを再利用したり、n 層をサポートしたりする必要がない場合でも、レイヤーを個別のクラス ライブラリに分割することを合法的に選択できます。純粋に組織的な目的や一貫性のためにそうするのが理にかなっているかもしれません。たとえば、別の開発者があなたの後ろに来て、「MyCompany.Feature.Business」というクラス ライブラリのクラスを見た場合、それらのクラスはすべてビジネス ロジック層の一部であると安全に想定できます。このように、コードを個別のクラス ライブラリに分割すると、自己文書化できます。

コードを dll に入れる理由は他にもあります。たとえば、プラグイン アーキテクチャのサポートや、一度にアプリケーションの一部を簡単に更新できるようになります。

于 2012-12-28T21:49:04.227 に答える