なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
グーグルは、JavaScriptでMVCアーキテクチャのアプリケーション開発をする際に便利な機能を備えたライブラリ「AngularJS 1.0」のリリースをブログで発表しました。 MVCアーキテクチャとは、ソフトウェアがデータモデル（Model）の部分とユーザーインターフェイスの部分（View）、そしてビューとモデルのあいだで制御する部分（Controller）に分離された構造のことを指します。 これらが分離されているとプログラムの見通しがよくなり変更にも対応しやすく、テストも容易になるため、何種類ものユーザーインターフェイスと複雑なロジックなどから構成される大規模なアプリケーションではMVCアーキテクチャの採用が望ましいものと考えられています。 しかしWebアプリケーションをMVCアーキテクチャで実現しようとすると、ビューの役割を果たすHTMLのコードの中に、どうしても複雑なJavaSc
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
せっかくUIパターンについて3つも記事を書いた(UIパターン その1、UIパターン その2、UIパターン その3)ので、自分でもコードを書いて試してみようと思った。 連鎖シミュレーションツール JavaScriptのコードはこれ(puyopuyo.js)。 モデルは2つ。fieldModel (6x12のフィールド)と、nextModel (次ぷよ)。observersフィールドにビューを追加しておくと、適宜update()関数をキックしてくれる。 fieldModelを書いたときにはgetter/setterをつけてみたのだが、まどろっこしかったのでnextModelではフィールドを直接公開してみた。 ビューも2つ。fieldViewと、nextView。どちらもupdate()関数を持つ。ビューを組み立てるときにはHTML DOMのノードコレクションを渡すようにしてい
Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、「アプリケーションモデル」、「モデルビュープレゼンター (MVP)」の5つ。なお、後ろの3つは、どれもMVCの変種だ。 氏のサンプルでは、「アイスクリーム濃度のアセスメント」というネタになっているが、ここでは「BMIによる肥満度判断」にする。実際のところ、動作はほとんど同じだ。 フォームとコントロール よくあるGUIのスタイルというか、VBに代表されるポ
Flex/AIRアプリのアーキテクチャ探索 その1 - [lib]の続きでプラガブルMVC（PMVC）を検索してたら、PMVCとModelModelViewController（MMVC）が一緒に出てきた。 （といってもどちらもMVCに比べたら全然情報が少ない） まずPMVC http://www.sra.co.jp/people/aoki/SuperAsciiJ/SAscii06.html UML的に表されて参考になるとこ http://careless-adventurers.net/?date=20071025 PluggableはModelのインターフェースをMとして挟んでMVCを構成、そのインターフェースモデル の後ろから実体を挿すということのよう。 MMVCはここの図6、図7にあたる http://www.sra.co.jp/people/nisinaka/Jun4Java/M
第6回 Smalltalkウィンドウプログラミング(2) 富士ゼロックス情報システム 青木淳 r2d2@bz90.fxis.fujixerox.co.jp はじめに ソフトウェア設計の第一人者であるジャクソン氏(JSD法で有名)が「プログラマにとって上達の第一歩は、動くプログラムと正しいプログラムを作ることの違いを認識することである。」と言われた[1]。Smalltalkウィンドウプログラミングを例に取りながら、ジャクソン氏の言葉を具現化するのが、前回(第5回)と今回(第6回)そして次回(第7回)の目的である。 前回では、ウィンドウのプログラムをゴリゴリ作るのではなく、そのプログラム自身を生成してしまうプログラム(メタウィンドウプログラム)を作成し、それを「ビュービルダ」と名付け、そのソースコードを示しておいた。 今回も、同じ機能を有する「ビュービルダ」を末尾にリストした。なぜ同じプログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
