mizchi / すべてのMVCを過去にする - GlidePlease note that Glide no longer supports Internet Explorer versions 7 or 8.
AngularJSのMVWパターンを理解する - Qiita
12/4の記事（AngularJSを使ったWebアプリのアーキテクチャ設計）で書くと言ったまま放置していたので、AngularJSのMVCパターンについて書いてみたいと思います。 AngularJSのMVCについては、12/19のお前のAngular.jsはもうMVCではない。と言われないためのTutorialというすばらしい記事がありますが、本記事ではもう少し抽象的な内容を扱ってみようかと思います。 MVW（Model-View-Whatever）パターンとは MVCパターンには、MVC2、MVP、MVVMなど数多くの派生パターンがあります。 目的は同じなのに派生パターンがたくさんあるのは、それぞれのプラットフォーム固有の問題（フレームワークの違いや、サーバサイドかクライアントサイドかの違いなど）によってMV*の*の役割が異なるからです。 AngularJSは公式ページで"Superhe
PHPerのMVCの一体どこが間違っていたのか - MugeSoの日記
メリークリスマス！ PHP Advent Calendarもいよいよ24日目に突入です。 昨日はxhprofについてでしたね。僕もパフォーマンスチューニングの際に使っています。手軽に利用できるのでお勧めです。 さて、このエントリーでは表題の通りMVCについて書かせていただきます。これは、PHPカンファレンス2012&WordCamp Tokyo2012合同LT大会で発表した「やはりお前らのMVCは間違っている」で煽るだけだったこの問題をきちんと解説するものです。 この発表資料を公開するとPHPの枠を超えて広く閲覧いただき*1、また多くの方から突っ込みを戴きました。「LTだから」と言って逃げていた回答をして、気持ち新たに新年を迎えようと思います。 MVCとはなんなのか 間違いを指摘する前にMVCがそもそもどういうアーキテクチャであるのかを確認しなければいけません。 MVCは1970年代にパロ
MVCの流れを簡単にまとめてみる - Qiita [キータ]
理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア
![MVCの流れを簡単にまとめてみる - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4eab66c03020ced4619e83c8ebe5ff0c4cbcd864/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9TVZDJUUzJTgxJUFFJUU2JUI1JTgxJUUzJTgyJThDJUUzJTgyJTkyJUU3JUIwJUExJUU1JThEJTk4JUUzJTgxJUFCJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJUE2JUUzJTgxJUJGJUUzJTgyJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1hNWRhZWZkYmY5ODQxZTI1ZWE2NjFjZGEzYjVjNmRmNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaGlyb2tpZGFpY2hpJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MmViZmQ0YmEwMzUxYTZmMGQyZjFhNWVhNzIyYjI2MA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D02e229a1404969c8e3f437e0d6b7bbe0)
やはりおまえらの MVC は間違えている in バックボーンジェーエス - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
続編の紹介 続編 やはり俺のMVCは間違えている in Backbone.js を書いた。そっちのほうが有益な情報が乗ってると思うけど面白くないかもしれない 以下本編 MVC の話と宗教の話と政治の話と野球の話はしてはいけないそうですがそんなの知るか俺はするぞ クライアントサイド MVC の話 そもそも MVC の出自が GUI アプリケーションのために生まれてきたものなので「クライアントサイド MVC」などと言う言い方をしなければならない状況がすでに憎いのだけれど、まあそれはおいておく。 「うちは Backbone.js を使っているから MVC でクライアントサイドが作られていて保守性が高いです」みたいなことを言う人間がたまにいるが、Backbone.js をつかったから（あるいは Marionette.js を使ったらから）といって自動的にお前のアプリケーションが MVC になるわけ
Rails のモデルはどうあるべきか - tomykaira makes love with codes
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
2012年に使いたいJavaScriptのMVCフレームワーク14選 - memo.yomukaku.net
1億総スマホが近づいたこの頃に、JavaScriptのMVCフレームワークに何を使うか？ node.jsと使ってみたいウェブアプリのフレームワークの候補を14選んでみました。 MVCフレームワークといっても、純粋なMVCだけではなく、MVVM、MVC2、MVPなど広義のMVCフレームワークを含みます。成熟したフレームワーク backbone.jsのように一定の歴史のあるものや、express.jsのようにnode.jsでのデファクト・スタンダードになっているようなものを含め、今すぐプロダクション環境で使用できる成熟度があると思われるフレームワークをまとめます。 Backbone.js http://documentcloud.github.com/backbone/ 古参のフロントエンド向けMVCフレームワーク。 node.jsに限らず、Rails等のフレームワークでもフロントエンド側の
いろんなJavaScript MVCフレームワークで作られた同一のToDoアプリで違いを学ぶ「TodoMVC」
JavaScriptでMVCの構造を持つアプリケーションを開発するためのフレームワークが10種類以上登場し、この分野が盛り上がっていることは、以前の記事「JavaScript MVCフレームワークはすでに十種類以上、その比較や最新情報などのまとめ」で紹介しました。 その各種JavaScript MVCフレームワークの違いを学ぼうというのが、Webサイト「TodoMVC」です。 ToDoMVCでは、AngularJSやBackbone.js、Ember.js、Spine.jsなど主要なMVCフレームワークを用いて開発したToDoアプリをまとめて公開しています。 開発されたToDoアプリはほぼ同一の外観や機能を備えています。これにより、それぞれのソースコードを見ることによって、各MVCフレームワークがどのようなコーディングスタイルを用いているのか、どのような機能を提供しているのか、といった違い
モデル・ビュー・コントローラ - Trygve Reenskaug - Digital Romanticism
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。（原文公開日：1979年12月10日） モデル モデルは知識の表象です。モデルは１つのオブジェクトであるかもしれませし（あまり面白くはありませんが）、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード（例えば、カレンダーの予定）を実装の詳細（例えば、パラグラフ）と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
MVC is dead, it's time to MOVE on.
MVC is a phenomenal idea. You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of … What? I’m certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it. To fix
サバクラ両方で動く JavaScript の大規模開発を行うために
サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te
Spring Rooのレイヤアーキテクチャ | かサハラノリオ |泳ぎ|漕ぎ|走り|ながら考える
先日の記事を詳細化していこうと思う。Spring Rooは、エンティティ層-Web層というシンプルな2層構造になっている。 レイヤを多層化し、責務を明確化することで、コードの可読性や変更性は向上する。なぜなら、どこに何が書いてあるか探しやすくなるし、DRY原則を徹底することができるから。 しかし、レイヤが多層になるほど、アーキテクチャは複雑になり、生産性は落ちる。一例としては、ドメインモデルの各レイヤへの射影が必要になることが挙げられる。永続化のレイヤでは、JPAやHibernateの永続化オブジェクト、プレゼンテーション層では、入力や表示しやすい形式(プレゼンテーションモデルと呼ばれることもある)での表現。サービス層ではこの2つを仲介するためのDTO。レイヤを行き来するためには、本来的には同じエンティティでありながら、表現形式の異なるこれらのオブジェクトの「詰め替え」がいちいち必要になる
matarillo.com: UIパターン
UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、
Backbone.jsを利用したクライアントサイドMVCの導入についてそろそろ書いておくか - 出町ミスド攻防記
jQueryヘビーなアプリケーションの問題点と、MVCによる構造化の必要性 jQueryは、ブラウザ上で動くJSアプリケーションの開発生産性を劇的に向上させました。DOM操作による動的なページ書き換え処理などは、セレクタを使ってちょろっとコードを書くだけで、ほんの数行で記述できてしまいます。 しかし、この方法の延長で、大規模なJSアプリケーションを構築することは果たして現実的でしょうか。例えば「GMail」や「New Twitter」程度の規模のJSアプリケーションを書かなければならないとしたら、どうでしょう？ 大規模なJSアプリケーションを開発するには、こういった手法を延長するのではなく、より洗練されたデザインパターンを導入する必要があります。この目的にぴったりのデザインパターンが、「MVC」デザインパターンです。 MVCパターンは、Webの世界ではサーバサイドプログラミングで広く知られ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next Generation Web Application Architecture