Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した
CakePHPという、1つのフレームワークの中での、1つのとらえ方については 他の方の回答が参考になると思いますが、一歩引いて一般的にMVCとサービスというのがどういう関係にあるのか、それぞれの言葉の意味という点で回答します。 質問ではMVCについて、次のように書かれています。 コントローラはユーザからの要求に対して必要な処理を抽出し、 ビューは結果などを伝えるために表示するもの、 モデルはコントローラから要求される処理をまとめておくものだと認識しています。 この分類はそんなに間違っているということはありません。しかし、実際「コントローラから要求される処理」にはいろいろな種類のものがあります。たとえば、 DBに情報を保存する／DBから情報を取得する メールを送信する アップロードされた画像ファイルのサムネイルを作成する があります。これらの何がモデルで、何がビジネスロジックで、何がサービス
愚痴です。 やはりお前らのMVCは間違っている http://www.slideshare.net/MugeSo/mvc-14469802 これ45k Viewあって、はブも600あって、Sep 26, 2012の投稿だからもおう1年以上前の話。つーかそれの波及記事もいろいろあってもう既に十分語り尽くされている、はずなのに… なぜか、未だにfat controller もうね。コード見るのが辛いんよ。つーか感覚的に分かりそうなもんじゃん。処理のエントリポイントがこんなになってていいのかなぁ?って。 改修案件でさ、コードどっから参照するよ?コントローラでしょ?んでさーコード調べるぞ!!ってなった時、そのコード見て、、、ため息出るでしょ。ひと目でわからんでしょ。 コントローラなんて,どのモデル読んでてどのview使ってるか、それだけで十分じゃん。パラメータの処理はルーティングでやればいいじゃん
あ、タイトルは釣りというか、なんかそれっぽいこと書きたかっただけです。ごめんなさい。 世間から3周くらい遅れてDCIというものの存在を知って、今さらネットで記事をあさって読んでたりします。この辺とか。 http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 http://uehaj.hatenablog.com/entry/20100528/1275011951 https://speakerdeck.com/kakutani/dci-sprk2012 http://mikepackdev.com/blog_posts/24-the-right-way-to-code-dci-in-ruby これらをいい加減に読んで、考えたのではなく感じたことをまとめると 従来よく利用されてきたMVCというアーキテクチャだとユーザーのメンタルモデルと齟齬
Symfony Advent Calendar JP 2012 - Day 3 ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。 賢すぎるエンティティはアンチパターンRuby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。 このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計
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の問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
twitter とか(もちろん自分のTL)で MVC アーキテクチャのことが話題になってるみたいなので、ちょっとメモ程度のことを書いておく。 まず、ここで言及してるのは、MVC2アーキテクチャのことではないので念のため。 Webアプリケーションは、一般的に三層アーキテクチャを採用する。プレゼンテーション層、サービス層、データアクセス層の3つ。でも、これはMVCアーキテクチャとは異なる。 Webアプリケーションでのコア部分はサービス層である。サービス層でWebアプリケーションで提供するサービスをきちんと構築するには、サービス層の中に MVC のうちの、少なくとも Model と Controller が必要になる。 プレゼンテーション層はまさしく View にあたる部分だけど、サービス層の中に View というか、UML で言うところの Entity・Boundary・Controller
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
まずは一言。 卒研しろ、俺。 ということで、こんなん書いてて良い時期じゃなくなってきましたが、書かないと忘れそうなので今の内に。 今回は、AndroidにおけるMVCアーキテクチャについてのお話です。 実は自分、半年くらい前に大学の授業でMVCについては学んでいたのです。iPhone開発で。 ただ、卒研でAndroidアプリを作り始めたら、どうやってMVCを構成したらいいか分からなくなってしまった。 で、本格的にアプリ制作に着手してから３ヶ月、ようやく自分なりにAndroidでMVCを実現する方法が掴めたので、ほぼ自分用の覚書として書き留めておきます。 ※大学生の与太話みたいなもんなので、鵜呑みにはしないでね！ MVCとは そもそもMVCって何よ、って話ですが、僕には説明しきれないので、この辺読んでください。 Model View Controller - Wikipedia MVCとは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く