5

UI層としてASP.NET MVC、ビジネス層としてWCF、データベースとしてSQL DBを使用して、3層アプリケーションを作成することを計画しています。

私のビジネス層は、サービス層 (WCF)、ビジネス層 (ビジネス ロジック、ビジネス モデル)、データ層 (エンティティ フレームワーク - DB ファースト) として分割されます。

  • データ層は、エンティティ フレームワークのエンティティを使用して、Get、GetById、Update、Insert などのリポジトリ メソッドを実装します。

  • ビジネス層は、ビジネス ルールとそのモデルで構成されます。（これはPOCOにあります）。

  • サービス層は、可能なサービス メソッドとしてビジネス機能を公開するだけです。

  • MVC の "M" は単なるプレゼンテーション モデルです。コントローラーが JSON / XML に変換してビューに渡すか、ビューで直接使用するために使用されます。

上記のアプローチは一般的ですが、これが良い設計であるかどうかを確認したいですか?

私の本当の質問は、レイヤー間のデータ転送についてです（UI（MVC）-サービス（WCF）-ビジネス-データレイヤー）

Account とその Traits をデータベースから取得するために GET 操作を開始したとします。データベースでは、2 つの異なるテーブルとして表されます。

  • アカウント --> アカウント番号、名前、タイプ
  • AccountTraits --> Id、AccountNumber、Category など..

Datalayer 内で、
EF を使用して、指定された AccountNumber のこれら 2 つのテーブル レコードを取得するメソッドを作成したいと考えています。

私のビジネス モデルには、Account と AccountTraits という 2 つのクラスがあります。AccountTraits のオブジェクト コレクションは Account クラスに集約されます。

お気に入り、

public class Account
{
    string AccountNumber;
    List<AccountTraits> Traits;
}

ここで、これらのドメイン オブジェクトにそのデータを入力する場合は、データ レイヤーで次のような EF クエリを使用できます。

public IEnumerable<Account> GetAccountAndItsTraits(string AccountNumber)
{
var query = from a in db.Accounts
            select new Accounts() {
            AccountName = a.AccountName,
            Traits = from t in a.AccountTraits
            ....

return query;
}

  1. これは、データ層 (EF) からビジネス モデル POCO を設定するための儀式的なアプローチですか?

  2. さて、いくつかのビジネス ロジックを適用した後、これらのコレクションを UI に戻したいと思います。これらをサービスレイヤーに転送するにはどうすればよいですか?また、UI モデルに渡すにはどうすればよいですか?

  3. ビジネスモデルとして正確なクラス定義を使用してWCFでDataContractを定義し、それに「データをコピー」してUIに渡す必要がありますか? 次に、UI は WCF プロキシ オブジェクトからデータを取得し、「そのプレゼンテーション モデルにコピー」する必要があります (これには、独自の Accounts と AccountTraits が必要です - いくつかの追加フィールドがある場合があります)。

これらのトピックに光を当てていただければ幸いです。

ありがとう！

4

1 に答える 1

3

WCF が提供する機能が特に必要でない限り、純粋にアーキテクチャに基づいて WCF を使用することは絶対にありません。つまり、特定のビジネス ツー ビジネス ニーズをサポートするための特定のトランスポート/プロトコルです。MVC には WebAPI があり、これは基本的に WCF から移行されたものと同じものであり、はるかに使いやすくなり、頭痛の少ないアーキテクチャのニーズを満たすことができます。

さらに、アプリケーションの外部で使用されることが確実にわかっているものを公開しない限り、WebAPI を使用することさえありません。このサービス層がこの MVC アプリケーションでのみ使用される場合は、それを廃止します。ビジネス層とデータ層を持ち、それがなくても関心の分離を維持できます。それは私自身の意見です。

通常、ビュー用に調整されたモデルであるビュー モデルを使用します。ビューまたはデータベースのいずれかを個別にリファクタリングでき、データ変換コードを変更するだけで済みます。つまり、変更されたデータベース フィールドは、クエリを調整するだけで済み、ViewModel は同じままであるため、そのビュー モデルを使用するすべてのビューは同じままです。クエリからエンティティをクエリして に変換するのとほぼ同じ方法で、ビュー モデル (特にビュー専用のモデル)new Accountに AccountVM という名前を付けます。

私は個人的に、コントローラーからこれらのタイプのデータ クエリ/変換メソッドを呼び出します。次にコントローラーは、AccountVM またはコレクションを に渡すだけです。vm は、AccountVM またはコレクションをView(vm)保持する変数の名前です。

これは、DB から View にデータを取得する方法です。EF エンティティ クラスと VM クラスは、通常はかなり似ており、場合によっては同一です。中間のビジネスエンティティクラスは、どちらか一方に似すぎて、追加のクラスと追加のコピーを実際に保証できないと思います。

私の意見では、いくつかの質問に答えます。 1 はい、基本的にこれは良いアプローチだと思います。

2 この GetAccountAndItsTraits は Controller から呼び出され、ビューはビジネス poco (または私が ViewModel と呼ぶもの) に基づいています。したがって、ビジネス層からのリターンは、モデルが期待するものと一致します。ここにはサービス層はありません。ただし、代わりに、ビジネス モデル関数が呼び出された後に発生する、EF エンティティをビュー モデルに変換するためだけの専用のメソッドをいくつか用意することもできます。言い換えると、ビジネス モデルは EF エンティティを返し、マッピング関数はそれらをその場合に必要なビュー モデルにマップします。これは、同じビジネス メソッドを利用する多数のビュー モデルとビューが存在する可能性があるためです。私は EF Code First を使用しているため、私のエンティティ クラスはすでに POCO にかなり近いものになっているため、それらが他のレイヤーに漏れても問題ありません。

于 2012-11-13T07:03:18.743 に答える