読者です 読者をやめる 読者になる 読者になる

MVCが嫌いな理由とか

MVCが嫌いだ。
積極的に取り入れる気にはなかなかなれない。

関心の分離、ファイル構造の複雑化

MVCはその特性上、関心の分離が重要視され、その結果、ファイル構造が複雑化することが多い。
正直、分かり難い。
慣れれば大丈夫・・・、とは結局ならなかったし、そこを乗り越えて採用するメリットを見出すこともできなかった。

もう一つの理由

もう一つの理由として、デザイナーにとって最も重要な見た目の定義(VIEW)が隠されているから。

改修のレベル

システム運用業務だと改修業務が発生する。これは致し方ないことだ。

  1. 見た目の改修
  2. ロジックを含めた改修
  3. データベースを含めた改修
  4. サーバやDNSの設定変更まで必要となる改修

実際には、軽微な改修である1、2のパターンが多い。
で、1についてはデザイナー自身に任せたい。

VIEWについて

通常、htmlファイルはURLに対応するフォルダに配置される。
システム化を行った結果、htmlは他のファイル形式に変更されるのだが、多くのMVCフレームワークは別フォルダに配置を移すことを要求する。
この時、関心の分離という名目で、デザイナーからVIEWが隠される。
彼らはエンジニアの手を借りなければ、文言一つ修正できなくなる。

継続的テストなどロジックの運用改修に程よく対応しているMVCフレームワークは多いが、デザイナー自身がHTMLを修正できるレベルでVIEWを修正できることを重視しているものはあまりないだろう。

せめて、システム化前後でVIEWの場所が変わらなければ。

世の流れ

個人的に魅力を殆ど感じてないのに反し、開発案件の委託をお願いすると「MVCフレームワークを採用させてもらいます」という開発会社が割と多い。
世の流れなのだろう。

初期開発は外部にお願いしても、その後の運用自体は社内で完結させることが通例である為、覚えざるを得ないのか、とは思っている。
運用時のメリットは全く感じないが。

既存アプリの改修として

委託先の開発会社の個性に引き摺られない為に(その後の運用をスムーズに行う為に)可能な施策として、既にあるアプリケーションを引き渡し、これを直して使ってくださいというのがある。
開発会社本来の力が発揮できなくなるのは、致し方ないといったところか。