「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
TopHatenar＋HatenarMapsのシステム構成 - kaisehのブログ
TopHatenarとHatenarMapsのシステム構成が、バージョンアップの度に複雑化してきて、自分でも把握しづらくなってきたので、整理する意味で図を作ってみました。 図に示したように、HatenarMapsは、S2RMIを使ってTopHatenarと協調動作しています。はてなダイアリーとはてなブックマークに関するデータをクロールしているのは、TopHatenarの側です。HatenarMapsの側では、TopHatenarのService層をS2RMI経由でコールして、集計済みのはてブ情報を取得し、クラスタリング処理の後にポリゴンを計算しています。その他、HatenarMaps上でコメントビームの表示等がリクエストされる度に、TopHatenarをコールしています。よって、HatenarMaps側のDBには、基本的にポリゴンデータしか入っていません。 以下、図中に出てくるフレームワー
100%失敗するWebアプリの作り方 - 最速チュパカブラ研究会
誰にとは言いませんが、私からの警告です。 要件 「Web上で日記を書いて、コメントをつけるシステムを作りたい」 普通の技術者の設計 えーと、日付ごとに分けてテキストを保存しておけばいいんだな。一日に複数の話題を書くこともあるだろうから、先頭に * がある行は見出しとして扱おう。コメントはシンプルなテキストで、各日付に関連させておけばいいな。 以上。 天才（自称）の設計 ふむ、コメントつきの日記システムか。凡人にはコメントと本文は別物のように見えるかもしれないけど、俺に言わせると実は同じものなんだ。だって、どちらも何かの話題に対して何らかの意見を述べているものだろ？ 違いは、ある話題のツリーのトップにあるのが本文、そこにぶら下がってるのがコメント。ツリーといえばファイルシステムだ。そう、つまり我々が作ろうとしているものはファイルシステムの一種なんだよ。日記を書けるファイルシステムというものを
インターフェイス指向設計 - naoyaのはてなダイアリー
本を読むこととは、その本を読んだことに費やした時間の間、その書籍のテーマについて考えを巡らせることではないか、と近頃思います。本を読みながら集中して、ある特定のテーマについて考え続ける。本を読み終えた頃には、その思考の量的な価値が、自らの中で質的な価値に変換されているというのが理想であり、それが読書の醍醐味ではないかと思います。 インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践 を読みました。この書籍はシステム設計における「インターフェイス」(ユーザーインターフェイスではなく、プログラムインターフェイス) についての書籍です。インターフェイスについて考えを巡らせるにあたって、思考のための指針を与えてくれる良著だと思います。 プログラムインターフェイスというものをどのように捉えるか。ファイルをブロック単位で読むための手順であるとか、ソートのアルゴリズムであるとか、そ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
