Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
プログラマが知っておきたいJavaと.NETの違い
システム開発がますます複雑化していく中、エンジニアには、テクノロジを理解して、さまざまな場面に適した選択が求められます。本連載では、Javaと.NETの基本的な仕組みから最新の傾向や技術などについて、数回に分けて紹介します いまさら聞けない、Javaと.NETの違い 今日、アプリケーション開発・実行のプラットフォームは、大きく2つのテクノロジに収束しているといえるでしょう。 1つは、エンタープライズ・アプリケーション開発の定番ともいえる「Java」です。 実行環境、開発環境の無償提供、OSを自由に選べること、フレームワークや開発環境が充実していることが人気の理由です。大規模アプリケーションの採用実績も多く、ほかのプラットフォームをリードしてきました。 もう1つは、マイクロソフトが発表した「Microsoft.NET」構想に基づいた「.NET」です。 プラットフォームが主にWindowsに制
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
Cプリプロセッサメタプログラミングで、文字列系泥沼関数型プログラミング - 簡潔なQ
今年の文化祭で書いた記事です。 - C言語といえば、いやなイメージ、過去の遺産といった感じがあるかもしれません。 C言語のネガティブな側面というと、やはりポインタやメモリ管理などが難しい、ということが思いつくかもしれません。 しかし、C言語のポインタは表記に騙されやすいだけで、仕組み自体は全く難しくありません。 文法も、どこぞのPerlやC++と比べたら屁でもない単純さです。 実のところ、仕様が煩雑で難しいのは、Cプリプロセッサなのであります。 普段からあまり複雑な使いかたをしないから気づかないかもしれませんが、Cプリプロセッサの置換処理は、欺瞞と裏切りに満ちた世界なのです。 これが進化するとテンプレートなどといったもっと面白いものになるのですが、今回はCプリプロセッサで計算をしちゃったりするところまで試しにやってみましょう。 (なお、GCCにより実験的に調べた記事なので、他のCコンパイラ
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
えせ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）を記録する場合を
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
ScalaによるWebアプリケーションフレームワーク「Lift」とは
Java仮想マシン上で動くオブジェクト指向＋関数型言語として、Scala（スカラ）が最近注目を集めています。Scalaで構築されたWebアプリケーションフレームワークはいくつかありますが、 本連載ではその中で比較的歴史のある（といっても2年程度ですが） フレームワークである、Lift（リフト）を紹介したいと思います。 はじめに Java仮想マシン（以下JVM）上で動くオブジェクト指向＋関数型言語として、Scala（スカラ）が最近注目を集めています。 Scalaで構築されたWebアプリケーションフレームワークはいくつかありますが、 本稿ではその中で比較的歴史のある（といっても2年程度ですが） フレームワークである、Lift（リフト）を紹介したいと思います。 対象読者 Javaは知っているが、Scalaも学んでみたいと思っている方 ScalaでのWebアプリケーション開発に興味がある方 必要な
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
