Q&A
MVCの考え方が最近良くわからなくなってきました。
- Model
- これまで - とりあえずModelはテーブル毎に作っていて、そのModel用の処理書いてました
- 悩み - テーブルを横断して取得したい処理をコントローラ毎に書いてたが、処理が重複してきた。この処理ってどこに書けば良いのだろうか・・
- Controller
- これまで - Controllerは画面毎に作っていたが、処理が肥大化してきた(バリデーション・Modelの操作(取得・挿入等)ので、Serviceを導入してみた。
- 悩み - Serviceを導入したは良いが、Controllerとの分け方がわからなくなってきた。
何か、分かりやすい考え方とかってあったりするのでしょうか。
どの説明も抽象的なので、出来れば実際の実装とか見れるとイメージ
が湧くかもしれないと考えております。
回答3件
0
MVCの「分け方」も、フレームワークや実装する人ごとに違ってくる印象があります。
自分自身はRailsを使っていますが、コントローラーに書きがちなコードの中で、
- バリデーション→データの一貫性を担うものはモデル自体に持たせ、不正な入力を弾く部分はコントローラーで行う（Rails標準）
- Viewを表示するのに必要なロジック…DecoratorやPresentorと呼ばれる層を導入して、そこに書く
- （例えばCSV取り込みのように）特殊なビジネスロジックが必要になる処理→専用のModel/Service（名前は違うけれど本質的には同じものです）を用意して、入出力をそこへ流すだけにする
このようにすれば、Controllerに残るのは、入力処理・Viewの表示と、それらのModel/Serviceへの受け渡しだけになります。
Modelはテーブルと紐付いたものに限らず、どんどん増やしてしまって構いません。「ある1画面に表示すべき情報をまとめて取ってくる」ようなものも、1つのModelとすることで領分がはっきりします。
クラスやメソッドなど「ひとかたまりとなったもの」は、長くなればなるほど長さに比例する以上に読みづらくなります。長いクラスを作るより、細かいクラスを多数作るようにしてください。
投稿2016/10/19 02:27
総合スコア145183
0
気持ちは凄くよくわかります。そしてこれからも同じことを何度も考えることになるかと思います。
MVCのレイヤ区別、MVC以外のコンポーネントとの区別、実は正解なんてないと思います。
ちょっと視点を変えた例を考えてみるといいかもしれません。
たとえば、アプリ自前のデータとは別に、サーバ内部から外部のAPIと連携してデータを送ったり取得したりして、その結果を画面に表示するケースがあるとしましょう。
この場合、「外部のAPI」は"データを保存するもの"としてとらえればModelと考えることもできますし、"画面表示や内部データの元になる情報を送るもの"としてとらえればServiceと考えることもできます。
要はアプリ内でどのようにレイヤを区別するかは、そのアプリのマクロな設計ではないでしょうか。そこも含めて開発でしょう。
投稿2016/10/19 02:14
総合スコア246
0
これまで - とりあえずModelはテーブル毎に作っていて、そのModel用の処理書いてました
ZendFrameworkでの話ですが、私の場合はmodels/Db/Tableというディレクトリを切って、その中に上記のモデルは入れています。
例えばuserというテーブルのモデルは
class Hoge_Model_Db_Table_User
みたいな感じで（別のフレームワークでもautoload機能は備わっているフレームワーク多いと覆うのでこれはフレームワークごとに適宜）
テーブル単位のモデルはその中でそれ以外の処理は別ディレクトリに入れる
例えばユーザー関連の処理をするクラスは
models/User の中に作っていく、、など
その処理が共通で使う事が多いのか、少ないのかでcontrollerに書くかモデルにしてしまうか悩みどころですが、
基本２箇所以上から使うならモデルにしてしまったほうが、修正が１箇所になるので楽なのでは？
投稿2016/10/19 02:57
総合スコア1689
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/10/24 00:00