0

私のモデルはデータの単なるダムコンテナでなければならないことを読みました。そのような魅力があります。この場合、私の理解では、コントローラーはリポジトリーを呼び出し、モデルをいっぱいにして、そのようにモデルを返します。

        using (var userRepo = new UserRepository())
        {
            var users = userRepo.GetAll();
            return View(users);
        }

AlertUserOrderHasBeenRecd（）のようなメソッドを追加したい場合、どこに配置しますか？

それをリポジトリに入れると、リポジトリはデータの永続性以上のことを行っています。

モデルに入れると、モデルはダムデータコンテナではなくなります。

注文モデルとユーザーモデルで渡され、EFについて何も知らなくてもアクションを実行するクラスを追加することもできます。

または、他の何か。

これを処理するための一般的に受け入れられている最良の方法はありますか？

4

2 に答える 2

2

このメソッドは、サービスレイヤーで定義できます。サービスレイヤーは、リポジトリからの複数のCRUD操作で構成される可能性のあるビジネス操作が含まれているため、リポジトリに依存します。次に、コントローラーはリポジトリではなくサービスレイヤーを取得し、その上でビジネスメソッドを呼び出します。

アプリケーションにさらに別の抽象化レイヤーを導入する代わりに、次のことができfavor query objects over repositoriesます。

于 2012-10-15T15:51:11.787 に答える
0

モデルとViewModelを分離することで非常に良い結果が得られました。ViewModelsは、データ（DTO）の単なるダムコンテナーです。モデルはビジネスレイヤー（UIのビジネス）です。したがって、結果は次のようになります。

  • コントローラ：サイト内のナビゲーションを処理します。
  • モデル：コントローラーによって要求されたViewModelを埋めて処理します。
  • ViewModel：表現されるデータを含むDTO。
  • ビュー：ViewModel内のデータの視覚的表現。

このアーキテクチャでは、メソッドはモデルに含まれます。

于 2012-10-15T15:57:46.190 に答える