[PHP]MVCモデルにおいて、M・V・Cのどこから開発するか

Question

お世話になっております。

現在、PHP（Laravel 5.2）で、サービス開発を行っています。

皆様、MVCモデル（Laravel関係なく）を採用している場合、
1人で1機能を開発する場合は、どこから着手されますか？

私自身、

1. モデル
2. コントローラー
3. ビュー

の順番で着手をするのが実装しやすいです。

が、今のチームで、ビューから作成することになり、
非常にコーディングしにくいです。
ビューだけ作って一度コードレビューが発生します。

皆様のご意見をお伺いできればと思います。

Answer 1

小さなシステムしか作ったことがない者の個人的な意見ですが、私がシステムを組む場合は、初期化や入力や集計処や出力などの各種の処理を縦軸に、ファイルや画面デザインや印刷デザインを横軸に並べたプロセスマトリックスチャートを作ってから開発します。そしてそれぞれのファイルや画面デザインなども大まかなデザインを描いておきます。開発しながらの多少の仕様変更もおこりますが、システムの全体像が見えていれば修正点と影響箇所が見渡しやすいので、臨機応変に対処できます。

ちなみに６年前にAccessで開発したe-ラーニングシステムのチャートが下図です。
　

　フレームワークによるMVCモデルではないですが、システムの全体像を俯瞰する意義は共通すると思います。
一応、もう少し機能を単純化したIIS上で働くASPスクリプトでWebシステム向けのバージョンも開発しました。

その手順からすれば、モデルもビューも同様にある程度形になっていた方が、処理で扱いやすいと思います。
質問の内容によれば、モデルの正規化やグループ集計用のキー項目の工夫などの必要性が後で浮かび上がってきて、蒸し返しが多発する可能性があり、その点をご心配なのでしょう。
逆にビューを明確にするとシステムの目的が理解しやすくなるので、それを狙ってビューを最初に固める方針ではないかと思われます。ビューもモデルもその他のシステムのエンティティもある程度は形にしておくとよいでしょう。さらに、改善点に気付いたときにその修正箇所と影響範囲を見通せるように、モデルとビューとそれに対応するコントローラとの関連性をチャート化しておけば、ある程度はオーバーヘッドも想定して手当てできるのではないでしょうか。

Answer 2

LaravelならWebアプリケーションですよね。

View先行の進め方なら、まずURLを決めて Controllerから着手します。
着手といっても中身はコメントとダミー変数だけにします。
コメントだけというのがコツです。

/user/show_profile/{id} としたURLならこんな感じでしょうか。

class UserController extends Controller {
    public function show_profile() {
        // 何を受け取るかをコメント
        //  GET,POST,Session,Cokkie,Env...
        // 例) 
        // GETパラメータのidを取得

        // 何のモデル、サービスを使うかをコメント
        // 例)
        // UserModelからidに一致するユーザ情報を取得

        // 何を返すか ダミーで作成します。
        $user = [
             'id' => 123,
             'name' => 'hoge',
        ];
        return response()->view('profile', $user);
    }
}

で、次にViewを作り以下を確認＆レビュー。

• UX,UI に問題ないか
• 送信方法はGET,POST,Ajaxどれにすべきか
• どのデータをどう取得するべきか
• レスポンスはHTML,リダイレクト,json,xmlどれにすべきか

問題があれば先のコメントとダミー変数を修正。再度、確認＆レビュー。

問題なく行けそうと判断できれば、コメントに沿ってModelやServiceを作りこみます。
その際は、全体をみて共通化できる処理がないか確認した方がいいでしょう。

この手法であれば、
・実際の画面を先に確認できる
・修正はコメントだけなので手直しを最小限にできる。
・コメントから処理内容をイメージできるので、他の人へ実装担当を渡すのも容易。
といったメリットがあります。

Answer 3

自分は普段Cakephpを使って、基本的には１機能を１人で開発していますが、あまりMVCのどこから作るという意識をしたことはないです。それよりは、その機能を実現する上で実装方法が不明確だったり、難易度が高そうなところから作っていきますね。または、その機能の中核をなす部分から実装します。それらを後回しにして、結局うまく行かなかった場合、手戻りが発生しそうだからです。
また、中核部分を最初に作るとデバックしやすいというのもあると思います。

例えば...
UIがメインの機能であれば、まずViewをしっかり作って、関係者にレビューしてもらうとか
課金などのビジネスロジックが重要な機能なら、Modelをしっかり作るとか

※なお、MVCどれか一つだけ作っても動かないので、どこからちゃんと作り込むかというレベルです

ある程度、中核が決まったら、細かいUI調整とか、バリデーションとか、ロギングとか肉付けしていくような感じでやってます。

今のチームで、ビューから作成することになり、 非常にコーディングしにくいです。
ビューだけ作って一度コードレビューが発生します。

運用がうまくいかないのであれば見直した方がいいかもしれませんね。
作っているシステムや体制にもよるかもしれませんが、ビューだけ作ってレビューしてもらっても微妙な可能性はあるかもですね（自分のプロジェクトでそれはやらないです）。なぜそうしているのかが書かれていないのでなんとも言えませんが...

Answer 4

私もまだまだ勉強中ではありますが、職場で FuelPHP を使ってて、だいたい Controller から着手します！
Controller はユーザーからのリクエストを扱う層で、作成するコンテンツの核となるロジックを書くので、そこを先にレビューしてもらえば戻り作業が少なくて済むからです。
デバッグも容易ですし。

View から作成しても View（ブラウザ）からの入力を受け取るのは Controller で、Model のデータを呼び出す処理も Controller に書くので、 Controller からレビューしてもらう、が適切かなと思います。

まぁでも View からでも Model からでも同時並行でもいいとは思いますが。