Q&A
そもそものController、Modelの意味や役割は理解の上で使ってますか？
Laravel、PHP関係なく、概念として。
お世話になっております。
当方Laravel5.5にてWebSiteを構築しております、
環境はmac OS Mojave10.14.2
ブラウザはGoogle Chrome バージョン: 71.0.3578.98になります。
悩んでいること
データベース上のレコードを複数取得して、
あるカラムの値を別の値に、例えば
idを文字列に変換する際(※)、
データの取得をControllerからモデルを呼び出して、
変換をサービス上のメソッドで行うとすると、
下記のどちらで実装するのがベストなのか迷っています。
※本件はEloquentでデータベースから値を取得する際に
joinや条件設定で設定できない値に変換したい場合
(データベース上に変換後の値がなく自分で生成したい場合)を指します。
下記取得したデータベースの値を$data
変換メソッドをconvert()とします
①変換メソッドをforeachする
php
1//foreachしてレコードごとにメソッドを呼び出す 2foreach($data as $key => $val){ 3 $this->CaseService->convert($val)}
②変換メソッドの中でforeachする
php
1$data_converted = $this->CaseService->convert($data) 2//convertの中でforeachしてデータレコードを変換する
考えていること
メソッドを毎度呼び出すのは処理速度が遅くなると思う一方で、
メソッドは他の箇所でも使用したいため、シンプルに
データを変換するだけ
(foreachを記載すると、渡すデータが1件の場合などの分岐を書く必要がある)
にしたいという思いもあります。
どちらで処理することが一般的なのでしょうか？
全て処理を書き換えて処理速度など比較して自分で確かめる事もできなくはないのですが、
初心者では配慮が抜ける部分もあるかと存じますので、
知見のある皆さまからのご意見をお聞きしたいです。
宜しくお願い致します。
mts10806様
修正依頼ありがとうございます。
Controllerはviewやmodelに対して司令(どのような処理を行うか)を記述する箇所で、
Modelはデータベースとの処理のルール(どのテーブルに対して、何をキーとするかなど)や
処理自体を記載する箇所と認識しています。
「ビジネスロジック」といった観点ではどうでしょうか。
ビジネスロジックというワードは聞いたことがあったのですが、
しっかり理解しておりませんでした。
「ビジネスロジックはモデル、コントローラーはできるだけview、modelへの司令や
ユーザー起因のデータの処理のみを記述する」
ということですね。
(参考：https://qiita.com/yamadamt/items/dc21a9510f1c2c6f5f3e)
今まで勘違いしておりました。。。
頂いたご指摘に質問で申し訳ないのですが、
以前勉強した中で(ソースは忘れてしまいましたが)
1つのテーブルに対して1つのModelを用意する
というものがあったことを覚えています。
もし、Controllerにビジネスロジックを記載しないとすると、
たとえばDataTableがあったとして、
DataModelの中には、
Data一覧取得時のメソッド、
Data詳細取得時のメソッド、
Dataダウンロード時の処理メソッド、
と並んでおり、Controllerでどのメソッドを
呼び出すか選択するというイメージであっていますでしょうか？
よくControllerの記載で見かける
Model::where(~~)
の処理はどういう区分なのでしょうか…
一覧の取得と1件の詳細の取得は対象のテーブルが同じでも、
処理が異なると思いますが、そうなると
ContorollerにModel::where(~~)のような処理を
記載すると一覧の処理か1件の詳細の処理かの分岐をControllerに
書かなくてはいけないのでは・・・と思ってしまいます。。。
回答2件
0
一般的には一括変換できる仕組みを提供するものじゃないですか？
例えばmb_convert_encoding()を配列に適用するときは
mb_convert_variables()をつかって一括変換します。
汎用的でない特殊なコンバート処理などの場合は
array_mapで受け取りながら吐き出していくのもよくありますね
投稿2019/03/29 04:27
総合スコア114839
yambejp様
ご回答ありがとうございます。
一括変換の際は別のメソッドがありその中で処理する
(foreachですかね)のが一般的ということですね。
初心者ですので、一般的な書き方を教えて頂いて非常に
助かりました。
勉強になりました、ありがとうございます。
また機会がありましたら、
宜しくお願い致します。
0
ベストアンサー
私見です。
コントローラはデータを取得してビューに渡すだけの役割をすべき、と考えます。
つまり、出されている案いずれでもなく、モデル側でコンバートしたデータを取得する処理を書き、コントローラはその処理を呼び出してコンバート済みのデータを受け取るだけにします。
コントローラにあまりガチャガチャ処理を書きすぎるとファットコントローラとなってしまい、場合によって同じテーブルを参照するのに同じような処理が散らばってしまってメンテナンス性も低下するため、コントローラ側にビジネスロジックはあまり持たないほうが良いという考えからです。
ただ、そもそも、modelsディレクトリ自体は現在のLaravelではなくなっているものであるくらい、開発者によって思想や定義が違う部分でもあるため、あくまで参考程度に。
投稿2019/03/29 04:49
総合スコア80850
mts10806様
毎度ご回答ありがとうございます。
それなりに構築してしまった一方で、
コントローラはクラスを分けることでそれなりに短く整理
されているので、今は要検討としますが、
ご指摘のようなファットコントローラ状態になるようでしたら
モデルにビジネスロジックを移していきたいと思います。
いずれにしても非常に勉強になるご回答でした。
不具合が生じる可能性が高いため避けた方が良いのか、
保守性が下がるから避けた方が良いのか、
どちらにもメリデメあるので考え方によるのか、
こういった区分を明確にご回答頂けていますので非常に理解がしやすいです。
いつもお世話になり非常に感謝しております。ありがとうございました。
また機会がありましたら、宜しくお願い致します。
そこはリファクタリングの領域ですね。
「単に短ければ良い」わけでもありません。
コードの統制がとれているか、設計思想にそっているか、共通化ができないか
そのあたりは実際は要件次第だったりもします。
こればかりは結構「コードだけ見せられても何とも言えない｣部分にもなります。
ロジックなので、きちんと結果さえ出ていれば筋道はひとつではありません。
より「全体像をとらえる力」が必要になります。縦の展開と横の展開を立体的に捉えられるように。
ここは私も現状に甘んじることなく精進していかなければいけないところ・・・
あなたの回答
tips
プレビュー
