かつてＪＲ横浜線 十日市場駅近くのMebius (CPU:Pentium 150MHz)より発信していたウェブログです。 １つ前のエントリーで、いわゆる"Model 2"がMVCパターンの用語で説明されるようになったことが、人々のMVCの理解をバラバラにする原因になった、と書いたが、そのことは、前エントリーの参考リンクの先のページでも見られるように、多くのWebページで触れられていることでもあるが、筆者はむしろ、いわゆるGoF本に書かれているMVCの説明が最大の混乱の元だと思っている。"Design Patterns: Elements of Reusable Object-Oriented Software"（邦訳タイトルは「オブジェクト指向における再利用のためのデザインパターン」）、いわゆるGoF本の§1.2にある以下の記述がそれである。 MVC consists of three k
▼Reenskaug (XEROX PARC) 「MVC」/ Things - Model - View - Editor MVC / XEROX PARC 1978-79 変化しにくいインフォメーションと変化しがちなプレゼンテーションとの分離。メンタルモデルの記述としてのMVCは失敗（続きは DCI, Data - Context - Interaction で）。Smalltalk-76, 1978。 ▼Reenskaug (XEROX PARC) 「MVC」/ Model - View - Controller(Editor) MODELS - VIEWS - CONTROLLERS Controller を追加。Editor は特殊な Controller として位置付け。Smalltalk-80, 1979-。 ▼VisualWorks (ParcPlace Systems) 「
なにやら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年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi O/R MapperとりわけActiveRecordによって、Model/Entityの区別がつかない人ってのが増えたうえに意味不明な思い込みでMVC批判してみたりとかMVACとか言い出してる状況に名前をつけたいな。 2011-03-20 15:46:58 広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi Entityとは、システム設計上のデータの一塊としての実体をさしていて、DBのRowとは本質的には無関係。ModelはMVCパターンにおいて、Controllerからeventをうけとり、Viewに修正を通知するインタフェースであり、実装としてビジネスロジック/ドメインを持ってる 2011-03-20 15:50:23 広木 大地/ エンジニアリング組織論への招待 @hiroki_dai
コミュニティーリソース Flex cookbook* (コードの共有) CSS Advisor (ブラウザ別バグ修正) Exchanges* (コンポーネントの共有) Adobe Labs* ユーザフォーラム RSS フィード* Flex バグベース* ユーザグループの検索* ユーザグループについて* Adobe Community Experts (ACE)* デベロッパーイベント* ブログ MXNA* (ブログアグリゲータ) Adobe ブログ* この記事では、Flex アプリケーションのアーキテクチャー概要を扱います。以下の内容は、Flex アプリケーション構築の際に一般的に起こる、と思われる問題への対応例を紹介することが目的です。Flex アプリケーションを常に同じ形で構築することを推奨するものではありません。 クライアント側とサーバー側を含めたアプリ全体のアーキテクチャーについて
厳密なMVCについて書こうかと思ったが、そもそも厳密なMVCはSmallTalkのMVCで自分はそれを知らない、ということに気がついた。つまり、MVCと名前の付く派生としてはrobotlegsとPureMVCくらいしか知らないので、自分の解釈は間違っているのかもしれない、という不安はある。よって、今回の話はそれらの派生MVCの話として、話半分に読んでほしい。 前回はMediatorがMVCとMCVの明暗を分けるとか何とか。Mediatorについては、MVCの細かい機能分けの話が絡むので、今回の話で。 厳密なMVCの機能分け MVCは制約をつけること（例えばpublicやprivate）で、誰もがわかりやすくて保守性の高いプログラムを書きましょう、という認識を持っている。これは、つまり、Model層、Controller層、View層に分けるということだ。 MVCをもっと仕分けすると色々出て
自分にはプログラムは書けないと遠い昔に思っていたが、稚拙ながらなんとか書けるようになった。そう思わせてくれたのはJavaだったが、今ではRuby言語やAS3言語たちと遊んだりしている。 MVCとの出会い そうしたアプリケーションの楽な作り方があったら知りたい、という気持ちがあった。基本的に、これらの言語で何を作ろうとしても、作法はあるのではないか。そうして出会ったのはMVCという概念だった。MVCについて学ぶ必然性を与えてくれたのがRuby on Railsで、より積極的に学んだのはPureMVCやrobotlegsというMVCフレームワークだった。 MVCというのは、GUI（グラフィカルアプリケーション）の制作において、有用な形だ。これを使うことで、複雑なアプリケーションのスパゲッティが、少しは食べられるものになる。 だけれども、MVCのことを知らないで、ほかの人が作ったMVCアプリケー
WPF/Silverlight開発において、イベント駆動開発じゃ何故いけないのか？ MVC/MVP/PMパターンとMVVMはどう違うのか、どういったメリットがあるのか？ そういう声を聴く機会は少なくありません。 MVVMパターンとイベント駆動開発、MVC/MVP/PMパターンとの関係について僕の理解をまとめました。 MVVMパターンをわざわざ適応する事に疑問がある方にはぜひ読んで欲しいと思っています。 また、このドキュメントを記述するにあたり@matarilloさん、@ufcppさん、@yfakariyaさん、諸先輩方３方に叩き台を見ていただき多くの指摘を頂くことができました。今回は頂いたフィードバックを受けて公開する形になっております。 押しつけがましくも一方的に依頼させていただいて、にも拘わらず非常に丁寧に様々な指摘・示唆を頂くことができました。 この場を借りてお礼申し上げます。ありが
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、
Overview If you haven’t read it already, be sure to check out this post where I talk more about the motivation for this tutorial. This MVC setup is perfect if you want to build an application like Jotlet.net, 280Slides.com, or even Gmail. If you’re aiming to build a more traditional web app like BaseCamp, Flickr, or Digg, then this still might be a good resource. A good rule of thumb: If you web a
You can use JavaScriptMVC as a complete framework, or download only the parts you need. Read JavaScriptMVC's features for more info. The Plan. Download JavaScriptMVC Read the Getting Started Guide Read the tutorials Browse the examples What People are Saying "JavaScriptMVC is the single most important reason why I don't hate client side development anymore." Mihael Konjevic, HibreedCMS "JavaScript
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1 はじめに SmalltalkのOJTを通して、「Smalltalkへのスムーズな導入」を行うために、いくつかの留意点があることを私は学びました。 ① データとアルゴリズムがパックされたオブジェクト(情報隠蔽) ② オブジェクト間コニュニケーション(メッセージ伝送) ③ クラスとインスタンス関係(メタクラスとクラス関係) ④ クラス階層構造(インヘリタンス機能) ⑤ アルゴリズムをデータとして扱うこと(closure/continuation) ⑥ Model-View-Controller(MVC) ⑦ 依存性(change&update) ⑧ プラガブルの考え方(pluggableMVC) ①〜④までは、オブジェクト指向プログラミングという形で多くの解説書が手に入りますので問題はありません。 ⑤は、LispやPrologを知っておられる方には簡単になじめます。アルゴリズムをデータとし
[id:soutaro:20050903] - http://www.jac-net.com/~tarzan/smalltalkers/mvc/mvc.html このURLは、最近見つけたのです。Smalltalkは詳しくないので、ソースコードまで確認していないですが、 モデルは、画面に表示したいオブジェクトそのものです。ところが、自分は「いつ、どこに、どの位の大きさで、どのように表示されるのか」という情報は持っていません。つまり、データ管理だけを専門に行うのがモデルの仕事です。 ビューは、モデルを「いつ、どこに、どの位の大きさで、どのように表示されるのか」を知っています。つまり、表示(出力)まわりを一手に引き受けるオブジェクトです。 コントローラは、モデルやビューを操作するためのユーザからの要求を受け付けます。そして、モデルやビューにメッセージを送り、全体の動きを制御します。指示(入力)
[id:lethevert:20050905:p5] - SmalltalkのMVC [id:lethevert:20050913:p4] - MMVC [id:lethevert:20050914:p1] - ドメインモデル貧血症 - 気のせいか、僕が、MMVCを見つけてリンクを張ってから、他のブログでもMMVCについてコメントしている記事を見かけたりしたので、こいつについてもうちょっと考えてみようかなと思います。 というのはですね、オブジェクト指向的なプログラミングを行う上で、MVCという考え方は基礎中の基礎のなのではないかと思うのです。デザインパターンなんて知らなくても、MVCは知らないとオブジェクト指向のデザインなんてできないでしょ、と思うのですね。しかも、今後、言語がどのように変化していったとしても、MVCは基本でありつづけるのではないかと思うのです。 モデル モデルはアプリケー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
