26

MVC 2 を理解し、将来の開発のための実行可能なプラットフォームとして会社に採用してもらうために、私は最近多くの本を読んでいます。過去数年間、ASP.NET だけを扱ってきたので、追いつく必要がありました。

現在、リポジトリのパターン、モデル、コントローラー、データ注釈などを理解しています。しかし、リファレンス アプリケーションの作業を開始するのに十分な理解を妨げていることが 1 つあります。

1 つ目はサービス層パターンです。Stack Overflow に関する多くのブログ投稿や質問を読みましたが、このパターンの目的をまだ完全には理解していません。MVCCentral で Golf Tracker Application のビデオ シリーズ全体を見て、彼が投稿したデモ コードも見ましたが、サービス レイヤーはリポジトリ パターンの別のラッパーであり、まったく機能しないように見えます。

この投稿も読みました: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspxそして、私の質問にいくらか答えているように見えましたが、データ注釈を使用して検証を実行している場合、これは必要ないようです。

デモンストレーションや投稿などを探しましたが、パターンを単純に説明し、それを使用する説得力のある証拠を提供してくれるものは見つからないようです。

誰かがこのパターンを使用する 2 年生 (OK、おそらく 5 年生) の理由、使用しないと失うもの、使用すると得られるものを教えてもらえますか?

4

2 に答える 2

36

MVC パターンでは、責任はモデル、ビュー、コントローラーの 3 人のプレーヤーに分けられます。

モデルはビジネスの処理を担当し、ビューはビジネスの結果を提示します (ユーザーからのビジネスへの入力も提供します)。一方、コントローラーはモデルとビューの間の接着剤のように機能し、それぞれの内部動作を分離します。もう一方。

モデルは通常、データベースによってバックアップされるため、それにアクセスする DAO がいくつかあります。あなたのビジネスは、いくつかの...うまく...ビジネスを行い、データベースに/からデータを保存または取得します。

しかし、誰が DAO を調整するのでしょうか? コントローラー？いいえ！モデルはすべきです。

サービス層に入ります。サービス層はコントローラーに高度なサービスを提供し、他の (下位レベルの) プレーヤー (DAO、他のサービスなど) を舞台裏で管理します。アプリのビジネス ロジックが含まれています。

使わないとどうなる？

ビジネスロジックをどこかに配置する必要があり、被害者は通常コントローラーです。

コントローラーが Web 中心の場合、入力を受け取り、応答を HTTP 要求、応答として提供する必要があります。しかし、RPC などと通信する Windows アプリケーションから自分のアプリを呼び出す (そしてアプリが提供するビジネスにアクセスする) 場合はどうすればよいでしょうか? じゃあ何？

そうですね、コントローラーを書き直して、ロジック クライアントに依存しないようにする必要があります。しかし、サービス層を使用すると、すでにそれが実現しています。書き直す必要はありません。

サービス層は、特定のコントローラーの実装に結び付けられていない DTO との通信を提供します。コントローラー (コントローラーの種類に関係なく) が適切なデータ (ソースに関係なく) を提供する場合、サービス層は呼び出し元にサービスを提供し、関連するビジネス ロジックのすべての責任から呼び出し元を隠します。

于 2010-05-04T05:46:52.997 に答える
1

上記のdpbに同意すると言わざるを得ません。ラッパー、つまりサービスレイヤーは再利用可能でモック可能です。現在、このレイヤーをアプリ内に含める過程にあります...ここに私が熟考している問題/要件のいくつかがあります(すぐに :p ) それはあなた自身の助けにはなりません...
1. 多くの異なるユーザーがアクセスする必要がある複数のポータル (ブロガー ポータル、クライアント ポータル、内部ポータルなど)。それらはすべて別個の ASP.NET MVC アプリケーションである必要があります (重要な要件)。
2. アプリ自体の内部では、データベースへのいくつかの呼び出しが似ています。メソッドとデータがリポジトリ レイヤーから処理される方法です。間違いなく、各モジュール/ポータルの一部のコントローラーは、同じ呼び出しの正確なバージョンまたはオーバーロードされたバージョンを作成します。そのため、別のクラス プロジェクトでコンパイルするサービス レイヤー (インターフェイスへのコード) が必要になる可能性があります。
3. サービス レイヤー用に別のクラス プロジェクトを作成する場合、データ レイヤーに対して同じことを行うか、それをサービス レイヤーと組み合わせて、モデルを Web プロジェクト自体から遠ざける必要があります。少なくともこの方法では、プロジェクトが成長するにつれて、データ アクセス レイヤー (つまり、LinqToSql -> NHibernate) を捨てることができます。または、チーム メンバーは、他のプロジェクトのコードに取り組むことなく、それを行うことができます。欠点は、彼らがすべてを爆破する可能性があることです笑...

于 2010-11-08T12:13:39.217 に答える