MVVMって何？ というか…MV○丸ごと、何？shibuya.swift #4 (http://shibuya-swift.connpass.com/event/31031/) で発表したスライドです。 もっと詳しいMVVMの話はこちら： 健康的なMVVM 書いてますか？ ~MVVMアンチパターン集~ (https://speakerd…
MVCの流れを簡単にまとめてみる - Qiita [キータ]
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存
![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)
L'eclat des jours(2013-10-25)
_ WebMVCと設計パターン WebMVC（面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい）というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装（貧血）と最悪のDomain Model実装（鬱血 ）が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど
いつまでPHPerはMVCを間違い続けるのか…? - どうにもならない日々@mkkn
愚痴です。 やはりお前らのMVCは間違っている http://www.slideshare.net/MugeSo/mvc-14469802 これ45k Viewあって、はブも600あって、Sep 26, 2012の投稿だからもおう1年以上前の話。つーかそれの波及記事もいろいろあってもう既に十分語り尽くされている、はずなのに… なぜか、未だにfat controller もうね。コード見るのが辛いんよ。つーか感覚的に分かりそうなもんじゃん。処理のエントリポイントがこんなになってていいのかなぁ?って。 改修案件でさ、コードどっから参照するよ?コントローラでしょ?んでさーコード調べるぞ!!ってなった時、そのコード見て、、、ため息出るでしょ。ひと目でわからんでしょ。 コントローラなんて,どのモデル読んでてどのview使ってるか、それだけで十分じゃん。パラメータの処理はルーティングでやればいいじゃん
ダブルMVCの意味するところ [GoGaRuCo 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=s1dhXamEAKQ TildのYehuda KatzのGolden Gate Ruby Conference 2013での講演。 Ruby on RailsのクリエーターであるDavid Heinemeier Hanssonが、「JavaScript勢はダブルMVCで苦しんでいる。サーバとクライアント両方にMVCが必要で複雑すぎる。」とTwitterで発言したのに対して、Yehudaは、それでは誤解を与えると危惧し、GUIプログラミングが歴史的にどのようにMVCに発展してきたかを紹介することで、ダブルMVCが本当に意味するところを解説しています。 DHHの発言は、盛り上がってきたMeteor / Node.js勢に対する単なる批判っぽいですが、それに対してYehudaはロジカルに話をまとめてます。 スライドを
雑把の UI アーキテクチャー史(MVCからMVVMへ) | プログラマーズ雑記帳
Web の場合は View と Controller の違いははっきりしてます。 View は html ページとその作成を担当します。 CGI は アドレスとパラメーター(アドレスの ? の後など)を受け取り、処理を行います。 その受け取り部分が Controller です。 Model と View ではなく、なぜ MVC としたのでしょうか ? 『 GoF 本』 では Controller を分ける利点をいくつか挙げられています。 キーボードの応答を変えたり、メニューからの呼び出しに変更するとき、表示方法を変更しなくていい。 入力イベントを無視するといったことをコントローラーのインスタンスの入れ替えで可能。 その他にも "View を入れ替えれば、 PC アプリ、 Web アプリでも使えるように" という理由もあります。 ちょっと無理そうな話ですが、例えば、 PC アプリが次のような
俺が勝手に考える正しいMVCの実装。モデルはデータAPI！ - はかますたいる！きょろの技的雑記
最近、一緒にコードを書く人（特にRailsから始めた学生さん）に、 MVC（Model - View - Controller）において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく！ 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
MVC、お前もか - みねこあ
MVC とは、もともとの出自は Smalltalk で、対話型のアプリケーションを作成するためのアーキテクチャのことでした。 Smalltalk なんて知らない人多いでしょうに、普通のプログラミングの話題でこうも顔をピョコピョコ出すのが、なんというか、憂いヤツです。そんな何かと気になるアイツこと、Smalltalk の MVC について、抜群にわかりやすいこちらの梅沢さんの記事をおすすめしておきます。 Happy Squeaking!! -オブジェクト指向再入門- [第五回：デザインパターン事始め] さて、こちらから引用して、MVC の M、V、C がそれぞれどんなモノかというと、 処理を受け持つ部分は、Modelと呼ばれます。アプリケーションで必要となる実際のデータを保持しており、業務に特化した処理を実行します。(中略) Modelの状態を表示する部分はViewになります。ビットマップデ
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
大きいMVCと小さいMVC 語弊を恐れずに書く - When it’s ready.
MVCって、大抵の場合サーバサイドでの実装の分け方の事を言ってるのが多い気がする。んで、サーバサイドを作ってる人々の多くは、UIに関してはデザイナーがhogehogeとか、タンポポワークほげとか言ってる場合が多い気がするんだけど、実際どうなんだろう？ 保存が必要なければ、ブラウザ内のJSだけでノートラフィック（初回DLは除く）でかなりのことが出来ると思うし、凝ったところはそうなっていると思う。MVCをサーバサイドとクライアントサイドで分けて考えると、実装者のリソースやら各データの祖結合具合だったりというのが上手に調整出来ると思うんだけどどうなんだろ？モデルにロジックてんこ盛り、否、コントローラも頑張るべきとか、いやいやテストすればモーマンタイでしょとかそう言うレベルじゃない気がする。 サーバーから動的に渡す部分はすべてJSONにして、それをサーバー側では最終アウトプット（View）にする、
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Flex/AIRアプリのアーキテクチャ探索 その1 - [lib]
MVCモデルでアプリを組もうとして、Viewへのデータをどう送ろうかと調べようとして、イベント駆動とMVCをキーワードに検索してたら、MVCよりいいよみたいな感じで PAC や PluggableMVC というのを見かけた。 （ちなみにMVCではObserverパターンを使うので、Flexではデータバインドを使うことになりそう。[Bindable]タグやmx.binding.utils.BindingUtilsを使うことになるはず。でもViewとModelが相互作用しないかが心配だった。どちらからだけ操作するならまだいいけども） ここでもFlexにPACはいいのではないだろうかと書いてある。 http://idm.s9.xrea.com/ratio/2007/08/14/000654.html まずPACを検索してみたが、PACもPresentation-Control-Abstracti
![Flex/AIRアプリのアーキテクチャ探索 その1 - [lib]](https://cdn-ak-scissors.b.st-hatena.com/image/square/799bb2365d37ce9e879064ca1ca738e9b87b99aa/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127061138723%2F17680117127061141687%2F1555756834)
GUI Architectures - 言語ゲーム
http://www.martinfowler.com/eaaDev/uiArchs.html ダン・ガメランさんに教えてもらったマーチン・ファウラーによる GUI アーキテクチャの紹介。まだ日本語訳は無いみたいです。 GUI ライブラリには大きく分けて Forms and Controls 系と MVC 系がある MVC 系ではモデルと表示を明確に分ける。モデルは表示に関わらない Forms and Controls UI を表現するフォームが、データを画面に表示する。 単純な場合、データバインディングがフォームとデータを同期する。 複雑な場合、イベントでデータを変更する。 Model-View-Controller (MVC) Model はデータとその処理を担担当 View は Model の表示を担当 Controller は Model の更新を担当 Model から View
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サバクラ両方で動く JavaScript の大規模開発を行うために
RIA のアーキテクチャーとデザインパターン （リッチクライアント編）
HugeDomains.com