MVCモデル

「モデル駆動アーキテクチャ」の理想とは裏腹に大規模開発における現実解として定着しつつある元祖「MVCモデル」。それから、クライアントにおけるもう一つの動向としての「リッチクライアント」に関する所感。

POJO志向

オブジェクト指向に興味があったり、真剣に勉強したいと思っているような人たちにとって、いわゆる「モデル駆動アーキテクチャ」は何とかして達成したい目標なのだと思いますし、同時にJavaEE5の整備やオープン系DIフレームワークが充実してきていることによって、「技術的な」実装基盤は整ってきているのではないかという感じもしています。


反面、「実際問題MDAをどう実現させるのか」という観点からすると、「大規模では難しい」という結論を持っている人も少なからずいるように思います。個人としては「大規模だから・・・」ということを言い訳にして何かを諦めるのは良くないと思いつつ、実際に反復可能な方法論が確立されていないことも事実であるような気がしています。


無論、MDAに関する理論整備はかなり進んでいると思うのですが、問題は、実際に取り入れるにあたっては、メンバーのスキルとプロジェクトの環境に依存するところがまだまだ大きいということですね。

MVC / トランザクションスクリプト / SQLテンプレート

O/RマッパーやDIフレームワークといったものがこれだけ充実してきているにも関わらず、「元祖StrutsMVC」「モデルはトランザクションスクリプトで手続き的に」「SQLはテンプレートに外部定義(O/Rマッパー?なにそれ)」という方法が、40人50人というPGさんを集めて作られる量産体制にはマッチしているようです。


原因はおそらく、「習得するべきスキル」が分かりやすいことなんでしょうね。

これら三つに加えてフレームワークを動かすために必要な「ちょっとした知識」があれば何となく作れてしまいますよ、という、乱暴な言い方をすれば、「ListとMapが使える」「htmlのテーブル構造が書ける」「SQLがある程度分かっている」でOKですよという手軽さが魅力なんだと思います。


こういう状況下においてプロジェクトの成否を分けるのは、実は「データモデル」なのではないかというのが最近の仮説です。*1

リッチクライアント

サーバサイドにおける「モデル駆動」の台頭とは別に、クライアント側でも激しい変化が起こってきているような気がします。BtoCのシステムではUIを充実させることがきわめて重要だというのは良く分かるのですが、社内事務処理系システムは今後どうなっていくのでしょうね。


個人的には「地図情報」のように業務仕様としてリッチなUIが必要なものを除けば、スタティックなhtmlでも別にいいのではないかと思っていたりもします。


MVCのコントローラがクライアントにシフトしている」という観点からリッチクライアントについて解説してある記事:
Tech Team Lead News: My clients are getting thicker and thicker: MVC implementation shift

*1:目の前のプロジェクトをどう成功させるかという問題とは別の次元で、「モデル駆動」のことは真剣に考えて行きたいと思っていますが。この辺についてはまた別の日に