回答編集履歴
1
リンクがちゃんと貼れていなかったので修正/見やすいように一部フォーマット
answer
CHANGED
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|
|
|
14
14
|
これらの問題は、リポジトリを上手く使えば軽減できます
|
|
15
15
|
|
|
16
|
-
実装面に着目すると
|
|
16
|
+
実装面に着目すると例えば、多くの開発者がテーブルの設計が変わってコードを何箇所も修正するような経験があるかと思いますが、リポジトリに操作を集約しておけばリポジトリを使う側の修正はほぼ不要になるので、そのような時でも対応が楽になるでしょう（テストや調査もしやすくなりますね）
|
|
17
17
|
|
|
18
18
|
ORマッパーなどの外部ライブラリに依存したコードもリポジトリの実装に隠蔽されるので、バージョンアップやライブラリ自体の変更に対応しやすくなります
|
|
19
19
|
|
|
@@ -21,17 +21,15 @@
|
|
|
21
21
|
|
|
22
22
|
以上のようなメリットを享受するためにリポジトリパターンは利用されます
|
|
23
23
|
|
|
24
|
-
（実装についてもう少し具体的に言うと、
|
|
25
|
-
リポジトリインターフェースを作成し、業務ロジックはそれに依存する（呼び出す）。そのインターフェースには、DIコンテナなどを用いて具象リポジトリをインジェクションする。ミドルウェアの変更などあった場合は、それ用の具象クラスを新たに作成しインジェクションする、感じになるでしょう
|
|
24
|
+
実装についてもう少し具体的に言うと、リポジトリインターフェースを作成し、業務ロジックはそれに依存する（呼び出す）。そのインターフェースには、DIコンテナなどを用いて具象リポジトリをインジェクションする。ミドルウェアの変更などあった場合は、それ用の具象クラスを新たに作成しインジェクションする、感じになるでしょう
|
|
26
25
|
|
|
27
|
-
これらはつまり抽象化によるメリットですので、対象のシステムで
|
|
26
|
+
これらはつまり抽象化によるメリットですので、対象のシステムで管理対象のクラスが増えることと比べて十分なメリットが得られないのであればリポジトリパターンは不要です
|
|
28
27
|
|
|
29
|
-
小規模なアプリに対しては些か過剰でもあります
|
|
28
|
+
小規模なアプリに対しては些か過剰でもあります
|
|
30
29
|
ですが、作っているアプリが将来的にどうなるかでも変わってくるので要不要の判断は非常に難しいです
|
|
31
30
|
|
|
32
31
|
なので、少しでも変更が容易くなるよう自動テストとかCIとかアジャイルとか諸々の手法の出番となるわけですが、本題とズレるのでおしまいにします
|
|
33
32
|
|
|
34
33
|
結局のところixaさんの開発しているシステムの属性で変わってきますので、上述したようなメリットとデメリットを踏まえた上でどうするのかを判断するしかありません
|
|
35
34
|
|
|
36
|
-
以下の記事など参考になるかと思います
|
|
37
|
-
|
|
35
|
+
[この記事](http://qiita.com/mikesorae/items/ff8192fb9cf106262dbf)など参考になるかと思います
|