質問: modelからDBにInsertさせる とりあえず、こう考えてみました。 ということは、indexでcontrollerのインスタンスでInsert()みたいなメソッドで処理が始まり、controllerではmodelのインスタンスを作りmodelでいろいろ処理をしている感じ?になるのかな?という感じです。 まぁ、この例程度の処理であれば、こういう処理をわけるほうがあっちこっちになるかもしれませんが、アドバイス等よろしくお願いいたします。
回答: 色々な意見があり、MVCパターンやら MVVCとか派閥に近いような思想が色々出てます。 なので個人的な意見だと思ってください。 ビジネスロジックという単語もよく出ますが、ビジネスロジックという単語の定義もおそらく思想によって多種多様なので、個人的には使わないようにしています。 ロジックはControllerに書くかモデルに書くか ========================== ControllerとModelの間にPresenter層を設けます。 ひとつのURLが1つのテーブルのみのCRUDを担当するなんてほぼ皆無で必ず複数のテーブルを処理します。 しかしORMなどはテーブル単位に処理されることが多く、そのURLの処理に特化してトランザクションを管理するレイヤーが必要です。 URL特化のロジックであれば直接ControllerとActionメソッドに書いちゃえば良いじゃんと思われますが、Presenterに書くのはHTTPから切り離した処理を書くようにしています。 つまり、Controllerの処理としてはHTTPとデータロジックの受け渡しです。 HTTPの処理とは ・CookieのデータGET,SET ・SessionのデータGET,SET ・ヘッダーのパラメータのGET,SET ・QueryStringのGET,URL生成 ・レスポンスの生成(リダイレクトも含む などなどです。 つまりControllerを見ただけでHTTPの流れのアウトラインが分かるようにします。 ・パラメータ異常->エラーページリダイレクト ・パラメータ異常->入力画面に戻す ・POSTからGETへのリダイレクト ・データ保存して結果出力 などなど。 これらを必ずControllerに書く必要は無く、Utilityクラスを作成してそちらに任せてもいいでしょう。 UtiltiyクラスはPresenter層に影響を与えてはいけません。 Presenter ========= Presenterに書くのはHTTPを完全に切り離した入出力です。 入力パラメータは1つのオブジェクトにしておくとメンテナンスが楽です。 出力オブジェクトも1つのオブジェクトにしましょう。それがViewModelになります。 こうすることでPOSTだろうがGETだろうがCookieだろうがSessionだろうが方針を変えてもPresenter層に影響はなく、Presenter層の単体テストが容易になります。 Model ===== Modelにはテーブル単体の良く使うQuery実行をメソッド化してまとめておきます。 slect文でjoinが必要な場合は良く使うものであれば左になる(基準になる)テーブルのModelに書きますが 大抵はその処理固有のものになるので直接Presnterに記述するのもありです。 Presenterのメリットとしてはたとえば会員登録のPresenterのメソッドであればそのメソッドからWebで実行したのと同じロジックでテストデータを大量投入したり、テスト用に使いまわすことができるようになります。 またフロントサイトの他CMSを裏で持っている場合、CMSから実行したりなども可能になります。 その他の意見 ====== Presenter自体をWebApiとして切り出してしまえばWebAPI経由で操作できるじゃんという意見もあると思います。それはその通りです。 考え方は個人個人だと思うので、ひとつの意見としてお納めください。 自分自身もこの考えに固執するつもりはなく、メンバーとの意見を取り入れてある程度みんなが納得できる仕組みで実装するのがいいと思います。