質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Entity Framework

Entity Frameworkは、.NET Framework 3.5より追加されたデータアクセス技術。正式名称は「ADO.NET Entity Framework」です。データベースエンジンに依存しておらず、データプロバイダの変更のみで様々なデータベースに対応できます。

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

.NET Framework

.NET Framework は、Microsoft Windowsのオペレーティングシステムのために開発されたソフトウェア開発環境/実行環境です。多くのプログラミング言語をサポートしています。

Q&A

解決済

1回答

2407閲覧

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

redhat98

総合スコア236

Entity Framework

Entity Frameworkは、.NET Framework 3.5より追加されたデータアクセス技術。正式名称は「ADO.NET Entity Framework」です。データベースエンジンに依存しておらず、データプロバイダの変更のみで様々なデータベースに対応できます。

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

.NET Framework

.NET Framework は、Microsoft Windowsのオペレーティングシステムのために開発されたソフトウェア開発環境/実行環境です。多くのプログラミング言語をサポートしています。

0グッド

0クリップ

投稿2017/12/15 07:44

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を意識するのは面倒だと思うから

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

ASP.NET MVC ですよね?

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

けど、

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

それと

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

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

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

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

さて

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

のであれば

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

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

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

投稿2017/12/15 22:47

hidori

総合スコア402

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2017/12/16 03:16

すっごい、参考になりました。 ありがとうございます。 > MVC の M から Repository を操作 ViewModel or Entityのどちらを指し示しているのでしょうか? ここだけ、イメージがつきにくいです。
hidori

2017/12/16 07:37

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

2017/12/16 08:21 編集

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

2017/12/16 08:22 編集

↑にさらに * データアクセス層に 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

2017/12/21 09:25

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問