1

C＃とRazorにASP.NETMVC3があります。アプリケーションのアーキテクチャは、データアクセス層（EFクラス+リポジトリ）、サービス層、コントローラー、ViewModels、およびViewに分かれています。

私のアプリケーションはダッシュボードであり、グラフを使用して製品に関する統計を表示する必要があります。

Productとテーブルがあり、グラフに1か月あたりProductCategoryの販売率を表示する必要があるとします。x軸には月があり、y軸にはProductPerCategory / ProductTotalのパーセンテージがあるため、と同じ数の行があります。ProductsProductCategoryProductCategories

この場合、私のドメインモデルはEF上のオブジェクトによって作成されProductています。私のリポジトリは、これらのドメインオブジェクトをその上位層（サービス層）に提供します。ProductCategory

私のビジネスモデルはProductGraphオブジェクトによって作成され、サービスレイヤーはこのビジネスオブジェクトをその上位レイヤー（コントローラー）に提供します。

私のコントローラーはこのProductGraphオブジェクトを取得し、ビューに表示するためにビューモデル ProductGraphViewModelにマップします。

モデル間のこの区別は正しいですか？レイヤー間で渡されるオブジェクトの定義に不足や悪いアプローチはありますか？

4

2 に答える 2

1

さて、あなたは私の素人の親指を立てています、これはかなり標準的なようです。考慮すべき他のいくつかの事柄は次のとおりです：1）あなたのDAL /サービス層はインターフェースされていますか？2）依存性注入を使用していますか（これらのインターフェイスをコントローラーのインスタンス化に渡します）？そうすれば、実装を切り替えたり、単体テストのモックを簡単に作成したりできます。

このブログ投稿は興味深いかもしれません。

于 2012-02-21T09:52:34.503 に答える
1

私自身のいくつかに尋ねることによってあなたの質問に答えます。

  1. 「ドメインモデル」と「ビジネスモデル」の違いは何ですか？それぞれが他よりも多い/少ない価値を与えますか？もっと知らなくても、同じものだと思います。

  2. サービスレイヤーにはどのようなメリットがありますか？人々（私自身を含む）は、実際にはリポジトリメソッドをラップするだけなのに、「サービスレイヤー」トラップに陥ることがよくあります。結局、ORMの詳細を消費するレイヤーに漏らしてしまい、そもそも抽象化のポイントを打ち負かしてしまいます。

レイヤー間のフローの例のコードを教えていただければ役立つかもしれません。

そして、はい、@sweaver2112はDIの使用についてスポットです。簡単なセットアップ、最大のメリット。

于 2012-02-21T10:16:44.527 に答える