4

私は従来の .NET MVC サイトを構築しているので、自然な 3 層のソフトウェア アーキテクチャ セットアップ (ビュー形式のプレゼンテーション、コントローラーのビジネス レイヤー、モデルとデータ アクセス レイヤーのデータ レイヤー) があります。

私がこのようなサイトを展開した場合、通常は 1 つのサーバー (Web サイトとデータベースが存在する場所) または 2 つのサーバー (Web サーバーと別の db サーバー) のいずれかになります。

3 サーバー アーキテクチャ (WEB、APP、および DB) をどのように処理しますか? Web サーバーにはプレゼンテーション (物理的な View/aspx ページなど) だけがあり、アプリ サーバーには構成ファイルと bin フォルダーが保持され、db サーバーはそのまま残りますか?

私の質問は基本的に、/bin とすべてのアプリ ロジックをプレゼンテーション ビューとは別のサーバーに移動することはできますか? もしそうなら、どのようにサーバーがどこを見ればよいかを知るように設定しますか? どこかに優れた入門書があるか、誰かが私に内情を教えてくれるなら、私は永遠にお世話になります.

4

5 に答える 5

6

MVCは3層アーキテクチャではありません。すべてのソリューションが3層またはn層である必要はありませんが、その違いを理解することは依然として重要です。MVCにはたまたま3つの主要な要素がありますが、これらの要素は「階層化」された方法では機能せず、相互に依存しています。

Model <----- Controller
         \       |
          \      v
           ---- View

ビューはモデルによって異なります。コントローラは、ビューとモデルによって異なります。したがって、これらの複数の依存関係パスは層として機能しません。

通常、3層ソリューションは次のようになります。

Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI

プレゼンター/コントローラーはややオプションです。たとえば、Windowsフォーム開発では、通常は表示されませんが、代わりに「スマートクライアント」UIがあります。これも問題ありません。

3つの主要な層（データ、ドメイン、UI）のそれぞれに依存関係が1つしかないため、これは3層のアーキテクチャです。従来、UIはドメインモデル（または「ビジネス」モデル）に依存し、ドメインモデルはDALに依存します。最近の実装では、ドメインモデルはDALに依存しません。代わりに、関係が反転され、後でIoCコンテナを使用して抽象的なマッピングレイヤーが挿入されます。いずれの場合も、各層は前の層にのみ依存します。

MVCアーキテクチャでは、Cはコントローラー、VはUI（ビュー）、Mはドメインモデルです。したがって、MVCはプレゼンテーションアーキテクチャであり、システムアーキテクチャではありません。データアクセスはカプセル化されません。ドメインモデルを完全にカプセル化するとは限らない場合があります。これは、外部の依存関係として扱うことができます。階層化されていません。

層を物理的に分離したい場合は、通常、ドメインモデルをWebサービス（つまり、WCF）として公開することによって行われます。これにより、スケーラビリティが向上し、関心の分離がより明確になります。ドメインモデルは文字通りどこでも再利用可能であり、多くのマシンに展開できますが、かなりの先行開発コストと継続的なメンテナンスコストが伴います。

サーバーアーキテクチャは、上記の3層図を反映しています。

Database Server <----- Web Services <----- Application

「アプリケーション」はMVCアプリケーションであり、ドメインモデルをWebサービスと（SOAPまたはRESTを介して）共有します。Webサービスは専用サーバー（または複数のサーバー）で実行され、データベースは明らかに独自のサーバーでホストされます。これは、3層、3サーバーのアーキテクチャです。

于 2010-04-11T19:06:01.770 に答える
4

一部のサークルでは、このコンテキストでの「レイヤー」が別のマシンを表す可能性があるn層とn層の違いとしてこの議論が表現されているのを見てきました。この定義を使用して中間層を作成するには、それをホストする必要があります。たとえば、プレゼンテーション層がデータを取得するために呼び出すサービス層がある場合、サービス層はプレゼンテーションまたはデータベースとは異なるマシン上にある可能性があります。ただし、そのサービスレイヤーは、WindowsサービスまたはWebサービスとしてホストされます。つまり、そのマシンでリクエストをリッスンするプロセスがあります。したがって、binフォルダーを別のマシンに単純に移動して、この作業を期待することはできません。これらのタイプのサービスを作成するためのWCF（Windows Communication Foundation）を検討します。

于 2010-04-11T17:06:01.033 に答える
1

ASP.NET MVC は、3 層システムのセットアップには役立ちません。これは実際にはフロントエンド パターンのみです。

多層システムの実装で解決しなければならない主な問題は、あるサーバーから別のサーバーへのオブジェクトの転送です。トランスポート チャネルに応じて、すべてのオブジェクトをシリアル化する方法を見つける必要があります。これは遅くなり、開発はより複雑になります。

別のアプリサーバーを用意する理由があります。他のアプリケーションが必要とするロジックが含まれている場合や、アプリサーバーが Web サーバーとは異なる権限を持っている場合があります。しかし、すべてのリクエストがリモート アプリケーション サーバーへの呼び出しにつながる、トラフィックの多い Web サイトを想像するのは困難です。

于 2010-04-11T18:25:28.270 に答える
0

次の論理的なスケールアップは、2台のWebサーバーと1台のデータベースサーバーです。

最終的には、多くのWebサーバーを追加した後、サービスレイヤーを追加する価値があるかもしれません。

また、拡張するときに、分散キャッシュ、セッション状態サーバー、電子メールサーバー、およびその他の専用サーバーをある時点で追加することもできます。

于 2010-04-11T17:10:59.580 に答える
0

だからあなたの質問は...

「/bin とすべてのアプリ ロジックをプレゼンテーション ビューとは別のサーバーに移動することはできますか?」

私の理解が正しければ、bin フォルダー内のファイルは、asp.net ページのコンパイル済みコード ビハインドになると思います。その場合は、いいえ、asp ページと同じマシン上にある必要があると思います。

プレゼンテーション レイヤーとは別のマシンにビジネス ロジックを配置する場合は、そのコードを別の dll にラップし、soap またはその他のプロトコルを介して公開する必要があります。プレゼンテーション層のコード。

于 2010-04-11T18:32:32.507 に答える