designとmvcに関するlizyのブックマーク (5)
-
_ 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は普通は作れないのでそれほど
-
最近、一緒にコードを書く人︵特にRailsから始めた学生さん︶に、 MVC︵Model - View - Controller︶において、﹁model = DB﹂だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく! 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの﹁逐次、反
-
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― ﹁matarillo.com﹂より ―― 猪股 健太郎 2011/12/15 ﹁.NET開発者中心 厳選ブログ記事﹂シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET/.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の﹃GUI Architectures﹄を訳して公開しようと思ったのだが、FAQページに﹁PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい﹂と書いてある。なので翻訳の公開はやめて、﹁
-
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく? まとめ 前提対象は Web アプリケーションで、画面数︵ビューの数︶は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います︵そもそも MVC を使わない、など︶。 肥大化するコントローラを避ける例えば、八百屋さんで﹁60円で仕入れたリンゴ1つを100円で売った﹂こと︵Sales Transaction︶を記録する場合を
-
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
-
1