Web で n 層ソリューションを見たことがありますが、それらはすべて各層に DLL を使用しています。私たちのアーキテクチャは同じように見えます: 3 つの DLL: データ レイヤー、ビジネス ロジック レイヤー、ビジネス オブジェクト レイヤー。ただし、プレゼンテーション層はこれらの層と直接通信するのではなく、WCF Web サービスを介してアクセスします。
ASP.NET MVC は、WCF WebService と同じマシンでホストされています。
それは良いアーキテクチャですか？ASP.NET MVC が他のレイヤーに直接アクセスできるとしたら、より論理的でしょうか?
最終的な回答ありがとうございます。
あなたのアーキテクチャはあなたの聴衆によって決定されるべきです。非常に多くのオーディエンス（期間ごとのリクエストで測定）がある場合は、説明したのと同様の方法でWebサービスを利用する分散アーキテクチャが必要になる可能性があります。ただし、聴衆が少ない場合、あなたが説明したアプローチは非常にやり過ぎです。
ただし、基盤となるDLLを更新する必要があるが、毎回Webサイトを再デプロイしたくない場合は、現在のアーキテクチャを維持するという議論があります。現在の設定では、Webサイトは影響を受けないまま、毎回Webサービスを再デプロイするだけです。ただし、繰り返しになりますが、非常にアクティブなWebサイトがない限り、DLLが変更されたときにWebサイトを再デプロイするかどうかはおそらく問題ではありません。
層の分割線の正しい数は、ウェブサイトがデータモデルにどれだけ厳密に従っているか、データベースでどれだけの重労働が行われるかなどに大きく依存します. ですから、答えるのは難しいです。
多くの人が十分な/多すぎる層を持っているかどうかを心配することに多くの時間を費やしていますが、残念ながら他の多くの人々は、他の人から指示された層を回避しようとして多くの時間を費やしています.
この質問に本当に答えるには、いくつかのことを考える必要があります
私は、これらのことが決して起こらないことを暗示しようとしているわけではありませんが、確かに起こりますが、多くのビジネスラインの多くの開発者にとって、理論があなたに信じさせるほどには起こりません.
このようなものの多くは、アプリの他の部分を書き直さない限り、現実的に置き換えることができないものから階層を作成しないことに帰着します。残りは、適切に設計されたものから時期尚早の最適化まで、どこで一線を越えるかを推測することになります。
IMHO - シリアライゼーションとエンコーディングのペナルティだけでは、Web アプリが常に同じサーバーで実行される場合は、UI を書くことはありません。後でサービスを別の場所にスケーリングするという理論上の必要性で最初にこれを行っている場合、その動機は理解できますが、キャッシュされたデータの有効期限やトランザクションなど、他の問題がいくつかあり、すべてを実際に実行する必要がある場合、これを依然として厄介な選択にすることがよくありますWCF サービスを介して。フィールドを追加するために変更しなければならないことの数が 3 倍になり、リレーショナル データベースを使用する多くの機能を利用できなくなります。
編集
OPは、WCFサービスが複数のフロントエンドの背後にあるため、サービスが常にUIと同じホスト上にあるとは限らないとコメントしました。MVC アプリにデータ オプションを追加して JsonResults などを返す場合は、MVC を使用して残りのエンドポイントを返し、メインの Web UI をバックエンドに完全に接続したままにするオプションがまだあります。