5

私はWebアプリケーションに取り組んでおり、後でそのモバイルアプリケーションも開発して利用できるようにする予定です。私はあまり経験がありませんが、このアーキテクチャを計画しているという理解に基づいています。

  1. WCFサービスと直接通信するMVCWebプロジェクトのフロントエンド。
  2. サーバー側の検証は、データ注釈を使用してMVCモデルで実行され、データはWCFレイヤーに渡されます。カスタマーメンバーシッププロバイダーを使用したセキュリティもMVCに実装されます。
  3. WCFレイヤーはビジネスレイヤーのようにも機能します。必要に応じて、クラスライブラリであるDALと通信します。
  4. EFを使用するDALはSQLServerと通信します*

質問してください

  1. このアーキテクチャは良いですか？
  2. WCFをビジネスレイヤーおよびサービスレイヤーとして使用するのは良いことですか？
  3. どのパッテンをどのレイヤーに実装する必要がありますか？
  4. データ検証とセキュリティのためにMVCは正しい場所ですか？

ありがとう

編集5.ユニットテスト に関しては良いですか？またはより良い証言のために私はいくつかの変更を行う必要がありますか？

4

1 に答える 1

4

あなたが説明しているのは、かなり現代的で優れたMicrosoftサーバースタックです。

ASP.net MVCは、WebUIに適しています。asp.net MVCを使用する場合は、ビジネスレイヤーのasp.net webapi（新規）も調べる必要があります。

http://www.asp.net/web-api

http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

SQLServerとEFはかなり標準的です。もう1つのオプションは、究極の制御が必要で、ストレートSQLに慣れている場合は、純粋なT-SQLです。

Web UI（MVC）をビジネスレイヤー（web-api）から分離することで得られる副次的な利点の1つは、最初は同じ役割/マシン上に存在する場合でも、役割を分離して独立してスケーリングできることです。また、クライアント側のhtml / javascriptコードは、web-apiへのajaxスタイルの呼び出しを実行できます。そのため、web-apiサーバーのエンドポイントを「登録」（構成）する必要があります。後でスケーリング/移動する場合、コードの変更はありません。最初の日から完全に分離してコーディングします。

モバイルデバイス（厚いアプリの場合）は、web-apiを直接使用できます。モバイルアプリが組み込みのブラウザー/javascriptソリューションを使用するハイブリッドモバイルアプリでない限り、MVCWebUIのほんの小さなフォームファクターのコンシューマーです。

テストのために、独自のコマンドラインプロセスでweb-apiをセルフホストし、可能であればデータをモックアウトすることができます。これにより、バックエンドなしでWebUIを検証できます。ビジネスレイヤー（Web APIによって公開）を使用することで、UIから独立してバックエンドとロジック（ロジックの大部分である必要があります）を検証することもできます。

于 2012-08-31T00:34:51.363 に答える