kaishitaeiichiの日記

MVCパターン

ソフトウェア, アーキテクチャ

MVCパターン

もう、8,9年前、自分がこの業界にはいるかどうかの頃、オープンソースのWebフレームワークもまだそんなにでまわっていないそんな頃、JavaでのWebアプリのプログラミングの勉強をすると、

• MVC(Model, View, Controller)パターンに当てはめて、サーブレットの開発をおこなうと、開発しやすくなるように、うまく実装を分離できる。具体的には、ModelがJavaBeans, ViewがJSP, ControllerがServletに対応する

のような説明を良く見かけた。

それらにくわえて、J2EE(JavaEEでなくてJ2EEだった)の勉強をすると、

• Webアプリでは、MVCでなくてMVC Model2(Web MVC)
• Webアプリでは、MVCでなくてBCE(Boundary, Controll, Entity ロバストネス分析というやつ)
• マルチレイヤ、多くは、3階層か4階層にレイヤ分けする
• Core J2EEパターン(フロントコントローラとかビューヘルパーとかビジネスオブジェクトとかDAOとDTOとか)

などの説明も見かけた。

MVCは、いまでも、それなりにきく言葉だ。

プログラミング言語によらず、よく利用されるWebフレームワークは、だいたい、MVC Model2(Web MVC)これなんじゃなかろうか。

以下に、MVCについての説明がうまくまとめてあった。

サバクラ両方で動く JavaScript の大規模開発を行うために

Web以前の、ローカルPCの、GUIのMVC

↓

Webアプリの、サーバ側のMVC

↓

JavaScriptの、WebアプリのMVC。サーバとクライアント両方

という流れで説明してあった。なるほどねえ。状況に応じて、ちょっとずつ変わってきていたんだなあ。

その他

まつもと直伝 プログラミングのオキテ - まつもと直伝　プログラミングのオキテ 第20回　MVCとRuby on Rail...：ITpro

従来のMVCと、RailsのMVC(WebアプリでよくあるMVC)を説明

Permalink | コメント(0) | トラックバック(0) | 22:28

pullかpushか

アーキテクチャ

AとBで連携したいとき、pullかpushか考える場面が時々ある。

こちらから、むこうに、はたらきかけて、データを引っ張り出すのが、pull。

むこうから、こちらに、はたらきかけられて、データを突っ込まれるのが、push。

こういう連携について、ちょっとメモしておこう。

バッチなんだけど、やたら他システムとの連携が多い、機能をつくっている。他システムが提供してくれている連携の仕組みは、たいてい、CSVファイルかWeb APIのどちらか。

たとえば、ブラウザとWebサーバは、ブラウザからWebサーバにリクエストをなげてレスポンスをもらう。ブラウザから、Webサーバに、はたらきかけて、データを引っ張り出す。H時々「Webサーバからpushできればなあ」と思うことがありつつも、HTTPは、基本pullという制約にしばられている。

そこをなんとかしたいと、がんばって、Webサーバからブラウザへpushできるようにした仕組みとして、Cometという技術もある。AdobeのAMFもたしか、HTTPの上位のプロトコルだけど、pushする仕組みを提供していたはず。

Webは、HTML5というかWeb Socketでもっとかんたんになるのかもしれない。

AとBで連携のタイミングが、はっきりとわからないときは、定期的にpollingするとかいうこともある。準備ができているかを確認して、準備ができていなければ、時間を置いてまた確認。準備ができていれば、そこでpullとか。

ファイルの受け渡しなんかもそうなのか。システムAとシステムBでファイルを受け渡しする。システムAのバッチの起動時間までに、システムBのバッチが必ずファイルをつくっているとは限らないから、システムAのバッチを起動するけど、システムBのバッチがファイルをつくってくれるまで、スリープしながら、ループして、待機とか。

データを受け渡しできなければ、リトライを適当に繰り返して、タイムアウトする。

AとBで直接連携しないで、メッセージングのミドルウェアを間に、はさむというのもある。

Permalink | コメント(0) | トラックバック(0) | 22:47