タグ

mvcに関するnitoyonのブックマーク (8)

  • MOVEは望まれなかった子 - the sea of fertility

    なにやら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年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう

    nitoyon
    nitoyon 2012/07/04
    PDS(PresentationDomainSeparation)の原則。M が Domain、V+C が Presentation。
  • グーグル製のJavaScript MVCフレームワーク「AngularJS」、正式版が公開 − Publickey

    グーグルは、JavaScriptでMVCアーキテクチャのアプリケーション開発をする際に便利な機能を備えたライブラリ「AngularJS 1.0」のリリースをブログで発表しました。 MVCアーキテクチャとは、ソフトウェアがデータモデル(Model)の部分とユーザーインターフェイスの部分(View)、そしてビューとモデルのあいだで制御する部分(Controller)に分離された構造のことを指します。 これらが分離されているとプログラムの見通しがよくなり変更にも対応しやすく、テストも容易になるため、何種類ものユーザーインターフェイスと複雑なロジックなどから構成される大規模なアプリケーションではMVCアーキテクチャの採用が望ましいものと考えられています。 しかしWebアプリケーションをMVCアーキテクチャで実現しようとすると、ビューの役割を果たすHTMLのコードの中に、どうしても複雑なJavaSc

    グーグル製のJavaScript MVCフレームワーク「AngularJS」、正式版が公開 − Publickey
    nitoyon
    nitoyon 2012/06/18
    テンプレートエンジン、Binding。公式サイトは twitter bootstrap、ソースは github。 (各種 MVC フレームワーク比較) http://www.publickey1.jp/blog/12/javascript_mvc.html
  • サバクラ両方で動く JavaScript の大規模開発を行うために

    サバクラ両方で動く JavaScript の大規模開発を行うために 原文:Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる? 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te

    サバクラ両方で動く JavaScript の大規模開発を行うために
    nitoyon
    nitoyon 2011/11/16
    JavaScript 開発のパターン。
  • 「RESTful MVC」なアーキテクチャの話

    最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)

    「RESTful MVC」なアーキテクチャの話
    nitoyon
    nitoyon 2009/10/26
    Model(DB+O/R Mapper+Business Logic)のインターフェースをJSONに。JS使えるブラウザはJSON(M)をWeb APIとして直接参照してclient side template(V)と結合、使えないブラウザはサーバ側ControllerでV(HTML template)と結合。
  • 平々毎々 (Hey hey, My my) | JavaScriptでMVPパターン(ぷよぷよ編)

    せっかくUIパターンについて3つも記事を書いた(UIパターン その1、UIパターン その2、UIパターン その3)ので、自分でもコードを書いて試してみようと思った。 連鎖シミュレーションツール JavaScriptのコードはこれ(puyopuyo.js)。 モデルは2つ。fieldModel (6x12のフィールド)と、nextModel (次ぷよ)。observersフィールドにビューを追加しておくと、適宜update()関数をキックしてくれる。 fieldModelを書いたときにはgetter/setterをつけてみたのだが、まどろっこしかったのでnextModelではフィールドを直接公開してみた。 ビューも2つ。fieldViewと、nextView。どちらもupdate()関数を持つ。ビューを組み立てるときにはHTML DOMのノードコレクションを渡すようにしてい

    nitoyon
    nitoyon 2008/10/08
    アプリケーションモデル(Model-View-Presenter)でぷよぷよ。
  • 平々毎々 (Hey hey, My my) | UIパターン その1

    Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、「アプリケーションモデル」、「モデルビュープレゼンター (MVP)」の5つ。なお、後ろの3つは、どれもMVCの変種だ。 氏のサンプルでは、「アイスクリーム濃度のアセスメント」というネタになっているが、ここでは「BMIによる肥満度判断」にする。実際のところ、動作はほとんど同じだ。 フォームとコントロール よくあるGUIのスタイルというか、VBに代表されるポ

    nitoyon
    nitoyon 2008/10/06
    GUI Architectures(http://martinfowler.com/eaaDev/uiArchs.html) を元ネタにUIパターンを解説。フォーム、古典的MVC→プレゼンテーションモデル、アプリケーションモデル。アプリケーションモデルはBindingを多用するときに参考になる。
  • 2008-02-01

    Flex/AIRアプリのアーキテクチャ探索 その1 - [lib]の続きでプラガブルMVC(PMVC)を検索してたら、PMVCとModelModelViewController(MMVC)が一緒に出てきた。 (といってもどちらもMVCに比べたら全然情報が少ない) まずPMVC http://www.sra.co.jp/people/aoki/SuperAsciiJ/SAscii06.html UML的に表されて参考になるとこ http://careless-adventurers.net/?date=20071025 PluggableはModelのインターフェースをMとして挟んでMVCを構成、そのインターフェースモデル の後ろから実体を挿すということのよう。 MMVCはここの図6、図7にあたる http://www.sra.co.jp/people/nisinaka/Jun4Java/M

    2008-02-01
    nitoyon
    nitoyon 2008/04/02
    Flex の設計をどうすべきか。この前後のエントリも興味深い。
  • 第6回 Smalltalkウィンドウプログラミング(2)

    第6回 Smalltalkウィンドウプログラミング(2) 富士ゼロックス情報システム 青木淳 r2d2@bz90.fxis.fujixerox.co.jp はじめに ソフトウェア設計の第一人者であるジャクソン氏(JSD法で有名)が「プログラマにとって上達の第一歩は、動くプログラムと正しいプログラムを作ることの違いを認識することである。」と言われた[1]。Smalltalkウィンドウプログラミングを例に取りながら、ジャクソン氏の言葉を具現化するのが、前回(第5回)と今回(第6回)そして次回(第7回)の目的である。 前回では、ウィンドウのプログラムをゴリゴリ作るのではなく、そのプログラム自身を生成してしまうプログラム(メタウィンドウプログラム)を作成し、それを「ビュービルダ」と名付け、そのソースコードを示しておいた。 今回も、同じ機能を有する「ビュービルダ」を末尾にリストした。なぜ同じプログ

    nitoyon
    nitoyon 2008/03/20
    ObserverパターンによるMVCのきれいな実装。
  • 1