JavaScript MVCフレームワークはすでに十種類以上、その比較や最新情報などのまとめ
グーグルが開発したJavaScript MVCフレームワーク「AngularJS」を紹介した1つ前の記事の反応が予想以上に大きく、1日たたずにブックマークが500以上もつきました。 本記事では、AngularJS以外にもすでにたくさん存在するJavaScript MVCフレームワークに関する情報をまとめて紹介したいと思います。 JavaScript MVCフレームワークの比較記事 既存のJavaScript MVCフレームワークを比較した記事が「The Top 10 Javascript MVC Frameworks Reviewed」です。Top10と書いてありますが、12種類のフレームワークの比較です。これは公開当時は10種類だったものが、その後11種類になり、今回のAngularJSの公開で12種類になったためです。 上記のような比較表を載せた上で、12種類すべての利点と欠点を説明し
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
MVCとRailsの基本構成を学ぼう
Web開発フレームワークとして人気の高いRuby on Railsの最新版、バージョン3を使ってWebアプリ開発の基本を学びます。 人気のフレームワークでWeb開発を学ぶ Ruby on Railsは、いまやWebアプリケーションの開発フレームワークの有力な選択肢の1つとなっています。Ruby以外の言語のWebアプリケーションフレームワークも少なからずRailsの影響を受けているので、現在Rubyを使っていないエンジニアにとっても、Railsを知ることは大いに参考になるはずです。もうすぐRails3認定試験が本格的に開始されるということもあり、この連載では、試験範囲の流れに沿って、Railsの基礎についてご紹介していきます（ただし、必ずしも試験対策というわけではありません）。 今回、連載第1回として本記事では、Railsを理解する上で基本となる考え方であるMVCについて説明した後、Rail
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Struts 2入門（1）～基本形で理解する仕組みと構造～
はじめに 「Apache Struts」（以下、Struts）とは、Web開発のデファクトスタンダードとしてあまりにも有名な、Java言語で書かれたオープンソースのWebアプリケーション・フレームワークです。JavaでのWeb開発者には、もはや説明する必要はないかもしれません。 最初のStruts（以下、Struts 1）がリリースされる2001年以前は、JavaでのWebアプリケーションというと、JSPとサーブレットを直接用いたアプリケーションが一般的でした。そのため、ちょっとしたアプリケーションでも、けっこうなコード量が必要だったのですが、Struts 1のフレームワーク機能により、煩わしい記述の手間がずいぶん少なくなり、Webアプリケーション開発の敷居がぐっと下がりました。 本連載は、そんなStruts 1の次世代バージョンであるStruts 2を紹介します。Struts 2は、字面
Webサービスの開発にフレームワークが必要な理由 ～Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門～
はじめに 前回はRuby/PHP/Perl、それぞれの言語ごとにフレームワークとテンプレートエンジンについて比較を行いました。これにより、現在のWebアプリケーション開発に求められる仕組みを俯瞰できたと思います。 今回はこの比較を基に、Ruby on Railsのこれまでの動向を追いながら、『どのようなフレームワークが自分にふさわしいのか』を考えていくことにします。また、最後に前回の記事で掲載しきれなかった各言語のフレームワークを紹介します。 「Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門」これまでの記事 第1回「効率的なWebアプリ開発の定石」 第2回「言語別フレームワークの比較」 フレームワークについて調査・分析を フレームワークの目的は、汎用処理を系統立てた仕組みの中に内包することで、プログラマの作業の効率化とWebアプリケーションの保守性を高めることにあります
Zephyr - AJAX Based MVC Framework for PHP5 Developers
zephyr is an ajax based framework for php5 developers. you can easily develop business applications using this robust framework. this is extremely easy to learn and very simple to implement. you can deliver a full fledged ajax application with strong business layer in backend within some minutes. installation and deployment of packages that you develop for zephyr is hassle free. moreover you will
Purchase Intent Data for Enterprise Tech Sales and Marketing | TechTarget
Enterprise Strategy Group: Go-to-market Expertise to Help You Win
Jemplate登場によるMVCアーキテクチャ進化の可能性 - Accept Things
2005年はAjaxが流行ました。AjaxによってWebアプリケーションの操作性が劇的によくなりました。しかしその一方で、Ajaxの登場によってWebアプリケーションのアーキテクチャに歪みが生じました。サーバーサイドのコードはMVCアーキテクチャによって綺麗に各層で役割分担ができていますが、クライアントサイドにおいてはそうではありません。現在多くのAjaxベースのアプリケーションでは、JavaScriptコードの中にロジックとHTMLコードを混在させるやり方でAjaxを実現しているため(恐らく)、メンテナンス性の低下を招いています。 そこで今回はこの問題を解決する新たな動きが最近見えてきたので紹介します。そして、新たに登場したJemplateによるMVCアーキテクチャの進化の可能性について考えてみます。 GoodPicの金子さんの予想 以前、GoodPicの金子さんが書かれた以下のエントリ
hide-k.net#blog: CatalystとStrutsのMVC実装の比較
PerlのCatalystとJavaのStrutsのMVC実装の比較をしてみます。 Struts Catalyst Model: Struts 図ではModelとしてActionFormとなっていますが、ActionFormはむしろViewに近い存在です。Strutsにおける実際の開発ではむしろJavaBeansをModelとして扱い、ModelのSerializeにはHibernateのようなO-Rマッピングツールなどを使います。SerializeにはDAOパターンを使うことが多いです。 Catalyst Catalystでは純粋なModelもフレームワークに組み込まれています。Class::DBIなどのActionRecord的アプローチを取るためModelそのものにSerializeの機能を含めることが多いためDAOなどを使う場面は少ないです。 Contoller: Struts
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サバクラ両方で動く JavaScript の大規模開発を行うために
言語別フレームワークの比較 ～Perl/Ruby/PHPユーザーのためのMVCフレームワーク入門～ (1/6)：CodeZine（コードジン）
Ywcafe.net
http://trimpath.com/project/wiki/TrimJunction