回答編集履歴
5
読みづらかった
test
CHANGED
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
-
その判断基準や全てのアクションをModelに記載してしまってはダメだと思うと書かれているのはクラスやメソッドの肥大化を懸念してのことでしょうか。
|
|
31
|
+
「その判断基準や全てのアクションをModelに記載してしまってはダメだと思う」と書かれているのはクラスやメソッドの肥大化を懸念してのことでしょうか。
|
|
32
32
|
|
|
33
33
|
|
|
34
34
|
|
4
誤字
test
CHANGED
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
-
LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。なので、Modelにコード
|
|
23
|
+
LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。なので、Modelにコードを書くことはむしろ一般的です。
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
3
文章の修正
test
CHANGED
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
-
LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。
|
|
23
|
+
LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。なので、Modelにコードが書かれることがむしろ一般的です。
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
|
@@ -28,13 +28,21 @@
|
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
+
その判断基準や全てのアクションをModelに記載してしまってはダメだと思うと書かれているのはクラスやメソッドの肥大化を懸念してのことでしょうか。
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
31
|
-
|
|
35
|
+
であれば、pa843さんが懸念している通り、アプリケーションの規模や設計によってはModelが肥大化することがあります。
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
その場合は必要に応じてModelに **ソフトウェアアーキテクチャ** を取り入れてください。
|
|
32
40
|
|
|
33
41
|
例:レイヤードアーキテクチャ、クリーンアーキテクチャ、オニオンアーキテクチャなど
|
|
34
42
|
|
|
35
43
|
|
|
36
44
|
|
|
37
|
-
ソフトウェアアーキテクチャを取り入れることで、Modelのクラス・メソッドが責務単位で分割される（単一責任の原則が守られる）ので
|
|
45
|
+
ソフトウェアアーキテクチャを取り入れることで、Modelのクラス・メソッドが責務単位で分割される（単一責任の原則が守られる）のでそれぞれの肥大化を防ぐことができます。
|
|
38
46
|
|
|
39
47
|
|
|
40
48
|
|
2
文章の修正
test
CHANGED
|
@@ -22,6 +22,8 @@
|
|
|
22
22
|
|
|
23
23
|
LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。
|
|
24
24
|
|
|
25
|
+
|
|
26
|
+
|
|
25
27
|
あくまでViewはページの表示やユーザーからの入力を受け付けるだけであり、Controllerはリクエストを受け取ってViewへの出力指示・Modelへの処理指示を行うだけです。
|
|
26
28
|
|
|
27
29
|
|
|
@@ -44,10 +46,10 @@
|
|
|
44
46
|
|
|
45
47
|
単一責任の原則を守ることのメリットは肥大化しないことです。
|
|
46
48
|
|
|
47
|
-
肥大化しないことのメリットは…、ここまで書けばきっと大丈夫でしょう。
|
|
49
|
+
肥大化しないことのメリットは…、ここまで書けば、きっと大丈夫でしょう。
|
|
48
50
|
|
|
49
51
|
|
|
50
52
|
|
|
51
|
-
特定のクラス・メソッドが肥大化するなら入れるべきであるし、そうでなければ入れなくても良い
|
|
53
|
+
特定のクラス・メソッドが肥大化するなら入れるべきであるし、そうでなければ入れなくても良いでしょう。
|
|
52
54
|
|
|
53
55
|
どれぐらいのコード量で肥大化していると感じているかはその人次第なので、リポジトリークラスを入れる基準もその人次第です。
|
1
文章の修正
test
CHANGED
|
@@ -20,19 +20,19 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
-
Laravel
|
|
23
|
+
LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。
|
|
24
24
|
|
|
25
25
|
あくまでViewはページの表示やユーザーからの入力を受け付けるだけであり、Controllerはリクエストを受け取ってViewへの出力指示・Modelへの処理指示を行うだけです。
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
29
|
-
pa843さんが
|
|
29
|
+
すると、pa843さんが懸念している通り、アプリケーション規模や設計によってはModelが肥大化するかもしれません。なので、必要に応じてModelに **ソフトウェアアーキテクチャ** を取り入れることがあります。
|
|
30
30
|
|
|
31
|
-
|
|
31
|
+
例:レイヤードアーキテクチャ、クリーンアーキテクチャ、オニオンアーキテクチャなど
|
|
32
32
|
|
|
33
33
|
|
|
34
34
|
|
|
35
|
-
取り入れることで、Modelのクラス・メソッドが責務単位で分割される（単一責任の原則が守られる）のでModelの肥大化を防ぐことができます。
|
|
35
|
+
ソフトウェアアーキテクチャを取り入れることで、Modelのクラス・メソッドが責務単位で分割される（単一責任の原則が守られる）のでModelの肥大化を防ぐことができます。
|
|
36
36
|
|
|
37
37
|
|
|
38
38
|
|
|
@@ -40,10 +40,14 @@
|
|
|
40
40
|
|
|
41
41
|
|
|
42
42
|
|
|
43
|
-
|
|
43
|
+
単一責任の原則を守れることがメリットです。
|
|
44
44
|
|
|
45
|
+
単一責任の原則を守ることのメリットは肥大化しないことです。
|
|
46
|
+
|
|
45
|
-
|
|
47
|
+
肥大化しないことのメリットは…、ここまで書けばきっと大丈夫でしょう。
|
|
46
48
|
|
|
47
49
|
|
|
48
50
|
|
|
51
|
+
特定のクラス・メソッドが肥大化するなら入れるべきであるし、そうでなければ入れなくても良いかもしれません。
|
|
52
|
+
|
|
49
|
-
どれぐらいの
|
|
53
|
+
どれぐらいのコード量で肥大化していると感じているかはその人次第なので、リポジトリークラスを入れる基準もその人次第です。
|