回答編集履歴
1
リンクがちゃんと貼れていなかったので修正/見やすいように一部フォーマット
test
CHANGED
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
-
実装面に着目すると
|
|
31
|
+
実装面に着目すると例えば、多くの開発者がテーブルの設計が変わってコードを何箇所も修正するような経験があるかと思いますが、リポジトリに操作を集約しておけばリポジトリを使う側の修正はほぼ不要になるので、そのような時でも対応が楽になるでしょう（テストや調査もしやすくなりますね）
|
|
32
32
|
|
|
33
33
|
|
|
34
34
|
|
|
@@ -44,17 +44,15 @@
|
|
|
44
44
|
|
|
45
45
|
|
|
46
46
|
|
|
47
|
-
（実装についてもう少し具体的に言うと、
|
|
48
|
-
|
|
49
|
-
リポジトリインターフェースを作成し、業務ロジックはそれに依存する（呼び出す）。そのインターフェースには、DIコンテナなどを用いて具象リポジトリをインジェクションする。ミドルウェアの変更などあった場合は、それ用の具象クラスを新たに作成しインジェクションする、感じになるでしょう
|
|
47
|
+
実装についてもう少し具体的に言うと、リポジトリインターフェースを作成し、業務ロジックはそれに依存する（呼び出す）。そのインターフェースには、DIコンテナなどを用いて具象リポジトリをインジェクションする。ミドルウェアの変更などあった場合は、それ用の具象クラスを新たに作成しインジェクションする、感じになるでしょう
|
|
50
48
|
|
|
51
49
|
|
|
52
50
|
|
|
53
|
-
これらはつまり抽象化によるメリットですので、対象のシステムで
|
|
51
|
+
これらはつまり抽象化によるメリットですので、対象のシステムで管理対象のクラスが増えることと比べて十分なメリットが得られないのであればリポジトリパターンは不要です
|
|
54
52
|
|
|
55
53
|
|
|
56
54
|
|
|
57
|
-
小規模なアプリに対しては些か過剰でもあります
|
|
55
|
+
小規模なアプリに対しては些か過剰でもあります
|
|
58
56
|
|
|
59
57
|
ですが、作っているアプリが将来的にどうなるかでも変わってくるので要不要の判断は非常に難しいです
|
|
60
58
|
|
|
@@ -68,6 +66,4 @@
|
|
|
68
66
|
|
|
69
67
|
|
|
70
68
|
|
|
71
|
-
以下の記事など参考になるかと思います
|
|
72
|
-
|
|
73
|
-
|
|
69
|
+
[この記事](http://qiita.com/mikesorae/items/ff8192fb9cf106262dbf)など参考になるかと思います
|