Entity FrameworkでRepositoryパターンを採用するか悩んでいる

Question

Entity Frameworkを使って業務システムを作ろうと検討中です。
その際に、RepositoryPatternを適用すべきか否かで迷っています。
みなさんはEntity Frameworkを使う時にRepositoryPatternを使っているのか教えてください

まず、想定している規模なのですが

1. 一覧画面 検索条件が5~10程度
2. 入力画面 伝票部の入力項目が10程度、明細部の入力項目8程度
3. 画面数 一覧画面10個、入力画面10個

そして、リポジトリパターンを使うか否かで悩んでいる理由が

1. ServiceとRepositoryの責務が曖昧になってしまうと気がしたから
2. 簡単な検索ならRepositoryを操作するよりも、Entityを直接操作した方が楽そう
   けど、複雑な処理はRepositoryに隠してしまったほうが、楽な気がするから
3. 単体テストを書く時はRepositoryを経由した方がテストが楽そうだから
   毎回、DBを意識するのは面倒だと思うから

です。経験談とかでもいいので教えてください。

Answer 1

ASP.NET MVC ですよね？

簡単な検索ならRepositoryを操作するよりも、Entityを直接操作した方が楽そう

けど、

は、そうなんですが、 EF のモックを作るのは結構しんどいです。

それと

複雑な処理はRepositoryに隠してしまったほうが、楽な気がするから

は、「複雑な処理」がビジネスロジックであるなら no だと思います。

ビジネスロジックはサービス層に配置したいところこです。

「複雑な処理」が DB に対するクエリの構築・実行であれば、それはビジネスロジックから見えないところに配置した方がいいですね。（Respsitory 層の領分）

さて

• 今後、システム規模が拡大する見込みは薄い
• サービス層に混み入ったビジネスロジックが無い

のであれば

• サービス層を省略
• MVC の M から Repository を操作

という選択もアリかな、と思います。

MVC の M にサービス層を兼務させる感じですね。

Comments

[redhat98]

すっごい、参考になりました。
ありがとうございます。

> MVC の M から Repository を操作
ViewModel or Entityのどちらを指し示しているのでしょうか？
ここだけ、イメージがつきにくいです。

[hidori]

>ViewModel or Entityのどちらを指し示しているのでしょうか？
すみません、逆に何を問われているのか分からないです。
「どちらを指し示している」の「どちら」は「MVC の M から Repository を操作」という文の中の何を指しているのでしょうか？

[hidori]

整理のために確認したいのですが、ASP.NET MVC の「MVC」はそれぞれ
* M = ViewModel + Model
* V = View
* C = Controller
と捉えている、という認識でよいですか？？

[hidori]

↑にさらに
* データアクセス層に EF を使用する
* システム規模が小さいので、出来るだけシンプルな設計を採用したい
* （このスコープでは）単体テストはビジネスロジックに重点を置く
という前提を加えて、ASP.NET MVC をどう構築するか？

具体的には
* ビジネスロジックをどこに配置するか
* データアクセスをどこに配置するか
* ビジネスロジックとデータアクセスは分離するべきか
という点に着目して考えるのが、本件の主旨と考えます。

最もシンプルな構築案（私見）は
「MVC の M の Model (≠ ViewModel）で EF を使用してする＝ビジネスロジック、データアクセスともに MVC の M に配置する」
です。
この構成はテスタビリティがよくないとされる場合が多いようです。

しかしながら、前言を翻すようですが、この構築案でも「それほど悪くない」テスタビリティを確保するとこは可能です。
* 単体テストの初期化で単体テストで使用する DB を作成して、単体テストで使用する DDL, DML の流し込みを行う
* 単体テストのクリーンアップ処理で↑DB を破棄する
とすればよいです。（個人的にはこれで結構回ると考えています）

もう一歩進めた構成案（私見）は
「MVC の M の Model (≠ ViewModel）で Repsitory を使用する＝ビジネスロジックは MVC の M に配置、データアクセスは Repository に配置」
です。
この構成の利点は、ビジネスロジックからデータアクセスを分離したことにより、ビジネスロジックにデータアクセスのモックを与えることで、実 DB にアクセスすることなく単体テストを実行できることです。
今回の質問に対しては、この辺までで留めておけばいいんじゃないかなーという印象です。

[redhat98]

丁寧にご説明頂きありがとうございました
ありがたすぎるレベルの技術解説です