MVC is a phenomenal idea. You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of … What? I’m certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it. To fix
この前、C#での画面遷移処理を簡単にするには、どうすればよいかについて考えていた。私の悪い頭じゃ何も思いつかなかったので、インターネットの力を借りて色々調べてみたら、素晴らしいライブラリを公開している方が居たので紹介。 該当する記事の紹介 Usa*Usa日記さんのところのまたしてもWindowsアプリでの画面遷移フレームワークについて フォーム間での変数の受け渡しの基礎についてもチョットで公開されている。関連するページをばらつかせて投稿されている様なので、以下にまとめておく。 関連記事 Smart.Windows.Mvc 0.3.1リリース ライブラリの最新版を公開されている記事。 Smart.Windows.Mvc補足 使用するまでの設定と、基本的な使い方。 Smart.Windows.Mvc補足(2) 発展的な利用法など。発展的とは言っても、この内容を活用できなければ真の便利さは得られ
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の問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
Presentation-Abstract-ControllerとModel-View-Controllerについてさらっと言及 MVCアーキテクチャはある程度の規模になると限界が訪れる。 http://c2.com/cgi/wiki?RecursiveModelViewController http://d.hatena.ne.jp/noopable/20090127/1233014697 この、1999年の記事でPACについて触れられているが、PACはMVCのスケール問題、その他を解消しうる。MVCでも、RecursiveMVCでMVCに階層構造を持ち込んで解決するという方法もあるらしい。 http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#fig:pac 似たようなことは誰でも一度は考えることだろう
1 はじめに SmalltalkのOJTを通して、「Smalltalkへのスムーズな導入」を行うために、いくつかの留意点があることを私は学びました。 ① データとアルゴリズムがパックされたオブジェクト(情報隠蔽) ② オブジェクト間コニュニケーション(メッセージ伝送) ③ クラスとインスタンス関係(メタクラスとクラス関係) ④ クラス階層構造(インヘリタンス機能) ⑤ アルゴリズムをデータとして扱うこと(closure/continuation) ⑥ Model-View-Controller(MVC) ⑦ 依存性(change&update) ⑧ プラガブルの考え方(pluggableMVC) ①〜④までは、オブジェクト指向プログラミングという形で多くの解説書が手に入りますので問題はありません。 ⑤は、LispやPrologを知っておられる方には簡単になじめます。アルゴリズムをデータとし
「PHP ○○ 作り方」みたいなキーワード検索するとべた書きの作り方がHitしまくる。 それなのにOOPなサンプルはあんまり見つからない。言語を英語にしても。 キーワードをMVCにすると結構ヒットするんだけど、殆どがフレームワークの使い方だったりして。 OOPの例としてよくあるのはオブジェクト指向プログラミングで書いたようなクラス単体のものだと思う。 でも実際何か作ろうとしたらクラスひとつで足りるわけがないし、クラス書いたすぐ真下で実行なんてしないじゃん？ ZendとかCakeとかPEARみたいなフレームワークを使って何かを作るにしても クラスをどうアレすれば掲示板とかになるの？って疑問は解決しない。 フレームワーク使えばそりゃ掲示板の一つや二つさくっと出来ますよ？ 出来るけどフレームワーク使うほどでもない時もあるし、OOPで組めって言われた時困るから本質が知りたい。 それで、探して見つか
![[PHP5] OOPで掲示板を作ってみる – Step1～Step2](https://cdn-ak-scissors.b.st-hatena.com/image/square/708927bb570ff8cf3d5d98c5975b0cce994ae1f5/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Ftenderfeel.xsrv.jp%2Fwtn%2Fwp-content%2Fuploads%2F2010%2F10%2Fstep1-preview.png)
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
Zend FrameworkのMVCで多様化しがちなビューを実現するには、Viewスクリプトは表示用テンプレートではなく、Viewをつかさどるコントローラー的に実装し、表示をフォーマットするためのテンプレートは別に用意したほうがいいのではないか。 多様化するビュー 一般的なWebフレームワーク同様、ZFのデフォルトのMVCではビュースクリプトをテンプレートとして扱うことが多いと思います。しかし、近頃のWebアプリケーションでは、さまざまなクライアントに対応しなければならないケースが多く、デバイスの違いや、使用するブラウザやRIAクライアントなどの違い、ユーザーステータス、表示アイテムのステータス毎の見栄えの調整など、ビジネス上のプレゼンテーションロジックもビジネスモデルに依存した多様なビューを必要としがちです。また、最近ではデスクトップアプリ並のインタラクティブ性を求められており、それらの
まずは一言。 卒研しろ、俺。 ということで、こんなん書いてて良い時期じゃなくなってきましたが、書かないと忘れそうなので今の内に。 今回は、AndroidにおけるMVCアーキテクチャについてのお話です。 実は自分、半年くらい前に大学の授業でMVCについては学んでいたのです。iPhone開発で。 ただ、卒研でAndroidアプリを作り始めたら、どうやってMVCを構成したらいいか分からなくなってしまった。 で、本格的にアプリ制作に着手してから３ヶ月、ようやく自分なりにAndroidでMVCを実現する方法が掴めたので、ほぼ自分用の覚書として書き留めておきます。 ※大学生の与太話みたいなもんなので、鵜呑みにはしないでね！ MVCとは そもそもMVCって何よ、って話ですが、僕には説明しきれないので、この辺読んでください。 Model View Controller - Wikipedia MVCとは
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet＋JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって？ ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発：第1回 Hello, Wicket｜gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Recommendations on how to design and develop custom applications using the Microsoft platform Each patterns & practices offering contains a combination of written documentation and re-usable source code. Many also include a reference implementation. As the guidance is being developed it is reviewed and approved by internal Microsoft product teams and by external customers and partners. This produc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
