私は、ソフトウェア アーキテクチャ、階層化に関する研究を行っており、Orchard CMS などの多くのオープン ソース .net プロジェクトを調べました。
Orchard はいくつかのデザイン パターンの良い例だと思います。
私が知っているように、UI、サービス、リポジトリ、およびエンティティは、誤用のため、別々のアセンブリにする必要があります。しかし、Orchard では、(モジュール性とプラグ可能であるため) サービス、リポジトリ、およびエンティティ クラスとインターフェイスが同じフォルダーと同じ名前空間に表示されます。
アンチパターンではありませんか、それともパターンに対して正しいですか?
1735 次
1 に答える
12
TL;DR: アセンブリは必ずしも適切な分離デバイスではありません。
いいえ、重要なのは、それらが別々のアセンブリにあることではなく、それらが分離されていることです。さらに、ほとんどのアプリケーションで物事を因数分解する方法は、拡張可能な CMS で行う方法とは異なる必要があります。拡張可能な CMS における適切な分離は、自由に追加および削除できる機能を分離することです。一方、通常の階層型アプリケーションでは、最小限のリスクと影響で作業およびリファクタリングできるようにレイヤーを分離する必要があります。正しい比較は、Orchard 全体ではなく、これらのアプリケーションの 1 つと Orchard のモジュールまたは機能との比較です。しかしもちろん、モジュール内で優れたプラクティスを使用する必要があり、通常は使用されています。
現在、アセンブリへの分離は別の問題であり、アーキテクチャよりも技術的です。アセンブリは、コードの再利用と動的リンクを目的として作成された自己完結型コードのコンテナーと見なすことができますが、特にレイヤーを分離する方法としてではありません。これが、Orchard でコード再利用の単位であるモジュールと一致する理由です。
また、これの実際的な側面も考慮してください。優れたアーキテクチャの実践には、アプリケーションをより簡単に、より安価に維持できるようにするという 1 つの主な目標があります (驚くべきことに (そうではありません!))。彼らは理解できる）。第 2 の目標は、スケーラブルでパフォーマンスの高いアプリケーションを作成する要素を成文化することです (ただし、ほとんどのソフトウェア悪の根源である時期尚早の最適化に簡単につながる可能性があるため、これはよりトリッキーな目標です)。
その最初の目標では、概念の分離が最も重要ですが、通常、この分離を行う方法はそれほど重要ではありません。
残念ながら、二次的な目標は、アセンブリを分離デバイスとして使用するという考えと矛盾します。Orchard には、オプションのモジュールを追加する前に、すでに数十のアセンブリがあります。また、アセンブリは無料ではありません。それらは、動的にコンパイル、ロード、jit され、メモリ オーバーヘッドなどを伴う必要があります。つまり、パフォーマンスを向上させるには、通常、アセンブリの数を減らす必要があります。
今日のように Orchard サイトをモジュールのアセンブリに分割し、これらの各モジュールをレイヤー化されたアセンブリに分割する場合は、モジュールの数にレイヤーの数を掛ける必要があります。数百のアセンブリをロードする必要があります。良くない。実際のところ、すべてのモジュールを単一のアセンブリにビルドする動的コンパイルのオプションも検討しています。
于 2012-05-27T19:42:12.987 に答える