大規模な Web フォーム ASP.Net アプリケーションを再構築し、サービス層を挿入して、プレゼンテーション層から不要な責任を取り除きます。
すべてのサービス メソッドが 1 つのクラスに含まれている例をたくさん見てきました。
これは一般的/ベストプラクティスですか? それとも、サービス層内に多数のサービス クラスを含めることは完全に実現可能ですか? 私は、複数のサービスを持ち、それらのサービスが互いに通信できるようにすることに傾いています。
ガイダンス、長所/短所はありますか?
リチャード
Ps 注意してください、私はWebサービス レイヤー、WCF、またはその他について話しているわけではありませんが、後日、より関連性が高くなる可能性があります。
SOLIDの原則、特に単一責任の原則は、すべての機能を 1 つのオブジェクトにまとめることは悪い考えであると示唆しており、私も同意する傾向があります。アプリケーションが大きくなるにつれて、単一のクラスを維持することが難しくなります。
Yuriys の回答に対するコメントは、IOC コンテナーを使用することを示唆しています。少し詳しく考えてみましょう...
この単一のクラスに含まれる機能が多いほど、より多くの依存関係が必要になります。クラスが多くの領域をカバーし、ロギング、データベース通信、認証などの下位レベルの他の機能に依存しているという理由だけで、パラメーターの長いリストを持つコンストラクターをサービスに配置することになる可能性があります。そのサービスのコンシューマーは、インスタンスを破棄する前に、そのクラスの特定のメソッドを 1 つだけ呼び出したいと考えています。IOC コンテナーは、サービスが実行時に「おそらく」必要とする可能性のあるすべての依存関係を注入する必要がありますが、消費者はそれらの依存関係の 1 つまたは 2 つしか使用しません。
また、運用上の観点からも、チームに複数の開発者が同時にサービス レイヤーで作業している場合、両方が 1 つのファイルを編集していると、マージの競合が発生する可能性が高くなります。ただし、示唆されているように、パーシャルを使用してその問題に対処できます。
通常、よく知られているパターンや原則に加えて実用性を高めることが最善の方法です。
ソリューションへのアプローチにおけるいくつかの重要な決定に答えるのに役立つ可能性があるため、まだサービス指向アーキテクチャを調査していない場合は調査することをお勧めします。
もちろん、それは可能です。さらに、この神のサービス レイヤー クラスからいくつかのインターフェイスを機能 (ISecurityService、INotificationService など) ごとに抽出し、各インターフェイスを別のプロジェクトに実装する方がよいと思います。また、サービスのインターフェイスを実装するクラスを解決するために、IOC コンテナーを利用することもできます。このようにして、クライアントの機能を変更することなく、各サービスの実装を個別に変更できます。
少なくとも、初めてサービス スーパー クラスを部分としてマークし、それを機能ごとに意味のある名前のいくつかの .cs(.vb) ファイルに分割し、それらを Visual Studio でグループ化することができます。これにより、サービス メソッド間の移動が簡単になります。
アプリケーションの構造化に関する私の見解は、アプリケーションを AppX.Web (UI ロジック) と AppX.Business (ビジネス ロジック) の 2 つのプロジェクトに分割することから始めますが、それらは同じ VS ソリューション内に保持します。ビジネス ロジックと UI ロジックの間の構造が明確になると、複数の Web ページ間で共有されるサービスと、単一の Web ページに対してローカルなサービスを理解するのに役立ちます。Web ページ間でコードを直接再利用することは避けてください。再利用が必要であることがわかった場合は、共有コードの一部をビジネス ロジック レイヤーに移動する必要があります。
ビジネス ロジック プロジェクトを実装するときは、さまざまな種類のビジネス ロジックに対して個別のクラスを作成するようにしてください。もちろん、これらのクラスは互いに通信できますが、Web ページ同士が通信することは避けてください。
UI ロジックをビジネス ロジックから分離したら、必要に応じて AppX.Business コードをさらに細かく分割できます。一般的な例は次のとおりです。
最後に、すべてを取り入れてビジネス ロジックを WCF サービスとして公開する方法について説明します。その場合、実際には既存の構造を変更する必要はありません。WCF サービスを既存の AppX.Web プロジェクトに追加するか、AppX.Service で個別に公開することができます。ビジネス ロジックを UI ロジックから適切に分離した場合、WCF レイヤーはビジネス ロジックの薄いラッパーにすぎません。
WCF サービスを実装すると、そのすべてを 1 つのクラスで行うことができます。ビジネス ロジックを直接呼び出すだけなので、WCF サービスでは実際のビジネス ロジックは使用できません。
新しいアプリケーションを構築する場合は、全体的な設計を前もって検討する必要がありますが、今は再設計しているため、段階的に作業する必要があると思います。