タグ

MVCに関するs-fengのブックマーク (6)

  • グーグル製のJavaScript MVCフレームワーク「AngularJS」、正式版が公開 − Publickey

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

    グーグル製のJavaScript MVCフレームワーク「AngularJS」、正式版が公開 − Publickey
    s-feng
    s-feng 2012/06/18
    MVC で最小限のコードでいけそうなのが分かりやすくていい。API連携の事例を試すと理解しやすいかも。
  • | 渋谷で働くエンジニア

  • Web アプリの MVC 設計まとめ - もやし日記

    MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく? まとめ 前提対象は Web アプリケーションで、画面数(ビューの数)は数個〜100個程度の規模です。WordPressTwitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います(そもそも MVC を使わない、など)。 肥大化するコントローラを避ける例えば、八百屋さんで「60円で仕入れたリンゴ1つを100円で売った」こと(Sales Transaction)を記録する場合を

  • あるRuby on Railsプロジェクトのふりかえり - yuum3のお仕事日記

    昨年末から始めた、Ruby on Rails を使ったある仕事がひと段落したので、ふりかえってみました。 この仕事で作ったWebアプリの詳細は書けませんが、画面数 60、テーブル数 15 と小規模のものでした。システムはところどころに難しい部分はありました、UIは一部に Ajax(JQueryを使用)を導入し使い勝手を高めています。 1. ソースコードが少ない! 書いたRubyコードの行数を合計すると 約3600行 しかありませんでした! 1画面あたり 60行しか書いてない !! ・・・「あんまり仕事してないじゃん!」と思わずつぶやいてしまいまました ^^); やはり、Ruby on Rails は生産性が高いと言われる通りです。 ただし、だらだらとコードを書かないように以下のように注意しました。 共通部分はモジュール化しMix-inで共有 継承による機能の共有は設計が難しくなりますし、委

  • Template Toolkit Manual -テンプレートツールキット和訳マニュアル-

    テンプレートツールキットマニュアル 職場でTTを使っていた時に少しずつ訳したものです。途中よく分からない所もあって、かなり適当。自動翻訳よりはマシかも、という程度です。 追記・修正歓迎。質問不可。→ しろいわ(public@hakoniwa.net) オリジナルマニュアル http://www.template-toolkit.org/docs/plain/Manual/Directives.html CPAN http://search.cpan.org/~abw/Template-Toolkit-2.14/ 概要 解説 テンプレート変数へのアクセス GET CALL SET DEFAULT 他のテンプレートファイル・ブロックの処理 INSERT INCLUDE PROCESS WRAPPER BLOCK 条件処理 IF / UNLESS / ELSIF / ELSE SWITCH /

  • Rubyでアジャイルプロトタイピング(3) - @IT:

    多くの開発者が、質の高いソフトウェアを生み出すためには、上の表にまとめたような問題解決手段を持つ、優れたプロダクトやプロセスを採用することが重要だと考えています。しかし同時に、人間1人1人と、人間同士で組織される顧客も含めたチームの能力を最大限に引き出すことこそが、さらに根的な重要事項であるということにも気付き始めています。この観点に立つと、既存のツールからもたらされる問題は、軽視すべきものではないことが分かってきます。ビジネス界の著名な思想家である故P. F. ドラッカー氏は、知識労働者の生産性を高めるのは、スキル、プロダクト、固定化されたプロセスといった生産手段ではないと述べています。同氏は、いかに賢く働くことができるかが、生産性を高める唯一の手段であると提言しています[注1]。 [注1]「プロフェッショナルの条件」 また、リーンソフトウェア開発の著者であるポッペンディーク夫は、開

  • 1