スケーラブルなプログラミングのために何が必要か - ジンジャー研究室
Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した
DCI(Data-Context-Interaction)からASI(Actor-Scene-Interaction)へ - ずっと君のターン
あ、タイトルは釣りというか、なんかそれっぽいこと書きたかっただけです。ごめんなさい。 世間から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というアーキテクチャだとユーザーのメンタルモデルと齟齬
DDD アンチパターン：賢すぎるエンティティ
Symfony Advent Calendar JP 2012 - Day 3 ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。 賢すぎるエンティティはアンチパターンRuby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。 このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計
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の問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
Webアプリケーション内のMVCアーキテクチャ - 今日の役に立たない一言 － Today’s Trifle! －
twitter とか(もちろん自分のTL)で MVC アーキテクチャのことが話題になってるみたいなので、ちょっとメモ程度のことを書いておく。 まず、ここで言及してるのは、MVC2アーキテクチャのことではないので念のため。 Webアプリケーションは、一般的に三層アーキテクチャを採用する。プレゼンテーション層、サービス層、データアクセス層の3つ。でも、これはMVCアーキテクチャとは異なる。 Webアプリケーションでのコア部分はサービス層である。サービス層でWebアプリケーションで提供するサービスをきちんと構築するには、サービス層の中に MVC のうちの、少なくとも Model と Controller が必要になる。 プレゼンテーション層はまさしく View にあたる部分だけど、サービス層の中に View というか、UML で言うところの Entity・Boundary・Controller
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
