shibuya.swift #4 (http://shibuya-swift.connpass.com/event/31031/) で発表したスライドです。 もっと詳しいMVVMの話はこちら: 健康的なMVVM 書いてますか? ~MVVMアンチパターン集~ (https://speakerdeck.com/takasek/jian-kang-de-namvvm-shu-itemasuka-mvvmantipatanji)
![MVVMって何? というか…MV○丸ごと、何?](https://cdn-ak-scissors.b.st-hatena.com/image/square/0c7b1f76912d804d4c0db73fb865eddcaac0ccde/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F6833bea1c3c545d1bf5600bc2d23f36f%2Fslide_0.jpg%3F6943921)
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
<この記事は「Money Forward Advent Calendar 2015」の22日目の記事です> この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
この記事はTrygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」を、氏の許可を得て翻訳したものです。(原文公開日:1979年12月10日) モデル モデルは知識の表象です。モデルは1つのオブジェクトであるかもしれませし(あまり面白くはありませんが)、複数のオブジェクトからなる構造かもしれません。 モデルとその一部には一対一の対応関係がある一方で、モデルとその所有者によって知覚された世界の表象との間にも一対一の対応関係があります。したがって、モデルの各ノードはその問題における識別可能な一部分を表象しているのです。 モデルの各ノードは、同一水準の問題を扱うものでなければなりません。問題指向の各ノード(例えば、カレンダーの予定)を実装の詳細(例えば、パラグラフ)と一緒にすることは混乱を招きますし、良くない形式と考えられます。 ビュー ビューはモデルの
なにやら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の問題点としてされているのは次の2点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
1. リッチクライアント 時代のWebアプリケーション アーキテクチャ パターンについて考える Next Generation Web Application Architecture. 2012-02-21 Ruby Sapporo Night vol.14 アップルストア札幌 日本Rubyの会 Ruby札幌 しまだ こうじ SHIMADA Koji 2012年2月23日木曜日 2. ...はるかな彼方の昔、ある場所で、何もなく無菌状態の空間 を漂っていた、でたらめに集まった原子の小さな集合に、そ れは深刻な外傷を与えた。そして、異常な、とてもありそう もないパターンで原子たちを離れないように結びつけてし まった。このようなパターンは自分自身をコピーするという ことを早いうちに覚えてしまい(これはパターンが非凡なもの であることの一面を示している) 、パターンが漂うすべての 惑星で、塊状
最近、一緒にコードを書く人(特にRailsから始めた学生さん)に、 MVC(Model - View - Controller)において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく! 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって? データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く