2019年05月22日に初出の投稿

Last modified: 2019-05-22

私がMVCフレームワークをもはや使わない理由

少し古い記事で、MVC のデザイン・パターンを利用したフレームワークの話をしている。僕も CodeIgniter や KohanaPHP といったフレームワークを使うことが多いので、この記事で指摘されている幾つかの話題に(賛否はともかく)思い当たることはある。

例えば、「よく調べてみるとReactの唯一の目的はビューを一連の(純粋な)関数へ分解することだということがわかります」という指摘を取り上げてみよう。フレームワークに限らず、WordPress の header() だろうとテンプレート式のウェブサイトで require() を使ってファイルを呼び出す方法だろうと、ヘッダを出力するコードだけ別のファイルとして扱い、リクエストされたファイルからユーザ関数のように呼び出して表示させている人は多いだろう。すると、条件によってあの呼び出し関数を使ったりこの呼び出し関数を使うという、色々な条件によって呼び出すソースの種類が変わってくると、呼び出し方としての API を適切に設計しておかない限り、全く場当たり的にユーザ関数が増えていく。そして、header01() を呼び出すことと header34() を呼び出すことの違いが明確になっていないなら、既に表示目的の違いが明確になっているソースから呼び出してもらうという馬鹿げた解決方法を採るしかなくなる場合もあろう。

ただ、この記事で著者はアプリケーション・アーキテクチャとしてのデザイン・パターンについて悩んでいるというよりも、ビューにおいてコンテンツやマークアップをどのように配置したり表示するかについて、React なりといった JavaScript のフレームワークがコントローラのようなことをするのはよくないと言っているように見える。しかし、それは JavaScript でビューから勝手に Ajax でコントローラを動かそうとする馬鹿がいるからであって、MVC というデザインパターンの問題ではない。特に、ここで話題にされている React は、DOM アクセスを通じてコンテンツをコントロールするだけではなく、DOM としての構造そのものを自ら作り出してしまうライブラリなので、データさえあればビューとしてどういうコードが書かれていようとお構いなしだ。コーダがソースコードに「Yes」と出力させたものを、フロントエンド・コーダ(フロントエンドの実装技術に「エンジニアリング」なんて存在しない)がブラウザ上では「No」として表示できる。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook