asp.net - WCFを使用してMVCプロジェクトを別々のプロジェクトに分ける

Question

私は、CMS とクライアント サイトを 2 つの異なるareas1 つの MVC プロジェクトで構成することに慣れています。この MVC プロジェクトは、その MVC プロジェクト内の両方の領域にサービスを提供するアプリケーション層(クラス ライブラリ) を参照します。アプリケーション レイヤーはドメイン レイヤーを参照し、ドメイン レイヤーはデータ レイヤーを参照します(どちらも独自のクラス ライブラリ内にあります)。MVC アプリケーションは、アプリケーション層のみを認識します。

私は、CMS を独自のアプリケーションに分離することの利点を望み始めています。そのいくつかは次のとおりです。

1. 多くの場合、非常に軽量なクライアント プロジェクトから、非常に大きな CMS プレゼンテーション コード ベースを取得します。
2. 特定のクライアント用のカスタム機能がない場合に、同じ CMS コード ベースを再構築する必要がない (多くの場合、新しいクライアント用に CMS を変更する必要はありません)
3. Web サイトへの影響を心配することなく、本番環境で CMS をアップグレードできる (逆も同様)

これを行うには、最初の調査から、アプリケーション層を参照する WCF アプリケーションを作成する必要があることがわかりました。ここから、CMS MVC アプリケーションとクライアント MVC アプリケーションは、WCF レイヤーとのみ通信します。

このアプローチの欠点:

1. ホスティング環境で利用可能な 3 つの個別のアプリケーションが必要です。
2. 異なるアプリケーション間のメッセージングのオーバーヘッド。

これは、私が望むものを達成するための最も簡単なアプローチですか? 同様の状況の例やわかりやすいケーススタディを誰か教えてもらえますか?

Answer 1

基本的に、アプリケーションをどのように保持するかは、あなたの選択です。ビジネス ロジックを後で Web サービスとして公開する場合は、WCF を使用する必要があります。これにより、CMS のビジネス ロジックがクライアント インターフェイスから独立するようになります。大まかに言えば、クライアントのみを変更する必要があり、BL を WCF に保持している場合は、サードパーティが開発できます。

私があなたの立場にいたら、間違いなく WCF のアプローチを採用していたでしょう。

そして、最も簡単なアプローチについて話す場合は、BL をプロジェクトの一部として使用してください。しかし、ここでもスケーラビリティと簡単な開発のどちらかを選択する必要があります。