MVC2 と Service層の関係 - 討論妄言録
あんまりひっぱつるもりもないし、言いたいことは言ったので蛇足感たっぷりだけど ^^; id:yugui さんのコメントは全くもって適切だと思う。で、せっかくコメントをいただいたので。前のエントリ「繰り返される MVC model 2 の話 - 討論妄言録」で主張している事を図に起こしてみた。 意図としては、特定のフレームワークに対する意見とかではなくて。あくまでもアーキテクチャとして MVC2 をどう理解すべきか、という点が焦点。 Model = DB の抽象化層とみなすと Model = DB の抽象化層とみなすと Model, View, Contoroller と同レベルに Service が語られることになる (図 1)。これだと、Service が存在しない構成にした場合に、当然ながら、複数のデータオブジェクトにまたがるトランザクショナルな処理を記述する場所が失われてしまう。その
繰り返される MVC model 2 の話 - 討論妄言録
以下、ここまでの流れを追わずに、主に放言だけ。いろんな方があれこれ書いていて。TL で目にしたのだけでも収集つかないし、断片的すぎるし、書いてる時にほとんど読んでいなかったので。他の人のは、ここから後で交錯した部分だけ引用させていただくよ。 話題の流れの情報収集 といいつつ、流れにはのっていない。(^^; 21:59:21 nsiena: 流れが分かってないけど、MVC2 が話題なの? | 22:04:22 uokumura: @nsiena ごめんなさいそこに飛んでるのたぶん私だけです。震源は http://bit.ly/ygzrQ ここです。 || 22:07:22 nsiena: @uokumura thx! 読んでまわるるる。 22:44:22 nsiena: #article 読んでる: 「Seaside へ GO!! -- 楽々サーバサイド Web プログラミング -- 第２回
仮想パネル：ソフトウェアアーキテクチャの文書化について
Len Bass氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、Software Architecture in Practiceと、もうすぐ第2版の出る "Documenting Software Architectures: Views and Beyond"の共著者。 Grady Booch氏, IBMフェロー、 Webサイト"Handbook of Software Architecture"の著者 Paulo Merson氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、"Documenting Software Architectures: Views and Beyond"の共著者 Eoin Woods氏, Barclays Global Inve
How We Made GitHub Fast
EngineeringHow We Made GitHub FastNow that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we've made in order to bring… Now that things have settled down from the move to Rackspace, I wanted to take some time to go over the architectural changes that we’ve made in order to bring you a speedier, more scalable GitHub. In my f
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
マルチスレッド・プログラミングの落とし穴、その２
ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと
Twitterがスケールに苦しむ理由 - スケールするサイトのアーキテクチャ考
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
memcached活用は、格納オブジェクトの”粒度”がキモ
最近じゃmemcachedを活用してデータベース(RDB)の負荷を下げるって話、そこらじゅうから聞こえてくるけれど、memcachedの活用は、格納オブジェクトの”粒度”（granularity）がキモだと思ってます。 memcachedは、KeyとDataをペアで格納して、Keyが与えられると、関連付けられたDataを返すだけのシンプルなシステム。PerlやPHPの連想配列と同じ。このmemcachedをRDBのキャッシュとして活用してやる場合、memcachedに格納するキャッシュデータの単位、”粒度”をどう設計するかが重要になってくる。 RDBの場合、格納されるデータはRow(レコード)単位。じゃぁキャッシュもRow単位で作ってやればいいのかといえば、それではうまくいかないケースもたくさんある。RDBでは専用の問い合わせ言語であるSQLを使って、 SELECT * FROM hoge
クラウド時代のトランザクション（2009-02-09 - きしだのはてな）
今のデータベースシステムでは、トランザクションはACIDという考え方が基本になってます。 これらの用語の頭文字をとってACIDです。 Atomicty 原子性：トランザクション中の処理は全部行われるか全く行われないか Consistency 一貫性：トランザクションが完了したとき、データの状態が正しい Isolation 分離性：複数のトランザクションが実行されても、完了してないトランザクションが他のトランザクションに影響しない Durability 永続性：トランザクションが完了したら、その状態は保存される。 ただ、分散システムでACIDを適用しようとすると、複数のサーバーで処理を分担させたときに一台のサーバーがこけてたらトランザクションが全く行えないとか、トランザクションマネージャーがボトルネックになってしまうとか、スケールアウトしにくくなってしまいます。 Brewerという人が、一貫
Webアプリ開発における「内部APIモデル」 - Tous Les Jours 攻防記
前回の話は、一回のエントリーでは書ききれない内容でした。。以下もうすこし詳しく書き直してみます。 Webアプリ開発における「内部APIモデル」とは、ネットワーク越しに外部サイトのWebAPIを呼び出すかのごとく、自サイト内のリソースに対して内部専用のWebAPIでアクセスする仕組みを導入し、分散処理を行うモデルのことです。典型的なWebアプリでは、データベースがここでいうリソースに該当するかと思います。 図にすると以下のようなイメージです。 今回、Lang-8で実際に「内部APIモデル」を導入してみたので、気づきの点などをこのエントリーにまとめてみました。 ※導入のいきさつについては、前回のエントリーで触れています。 「内部APIモデル」を採用するメリット Webアプリ開発において「内部APIモデル」を採用するメリットは２つあります。 （１）言語やフレームワークの選択自由度が上がる 現在運
システムアーキテクチャ構築の原理 - 廻る技術の覗き穴
システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践) 作者: ニック・ロザンスキ,イオイン・ウッズ,榊原彰,牧野祐子出版社/メーカー: 翔泳社発売日: 2008/12/03メディア: 大型本購入: 15人 クリック: 355回この商品を含むブログ (16件) を見る アーキテクチャ設計の際には、ぜひ手元に置いておきたい一冊。 設計に関する書籍はスタイルやパターンについて書かれたものが多いが、本書はステークホルダ、スコープ、パターンに始まり、データ構造、運用、セキュリティ、パフォーマンスなど取り扱う範囲が非常に広い。 しかし網羅性は高いものの、各項目はそれほど詳細に記述されているわけではない。詳しく学びたい場合は、各章で参考文献が紹介されているので、それらを参考にするのがよいだろう。 また、実際の設計の
RailsとREST - 『アーキテクチャの生態系』 | poqu.log
濱野智史さんの『アーキテクチャの生態系』を読んでいる途中なのですが、この「アーキテクチャ」の肯定的な捉え方に、RailsとRESTの関係が思い起こされたのでメモを。 濱野さんによる『アーキテクチャの生態系』の紹介はこちら。 アーキテクチャって？ ここで呼ばれている「アーキテクチャ」とは、ローレンス・レッシグ『CODE』で説明されていたものです（最近はver. 2.0が出ています）。 レッシグさんは、人の行動や社会秩序をコントロールするためには、４つの方法があると言っています。それは、規範（慣習）、法律、市場、そしてアーキテクチャです。たとえばタバコを吸わせないように人の行動をコントロールするためには、これら４つの方法をどのように使えるでしょうか。 規範（慣習） 人の行動はマナーのような規範で制約することができます。分煙という規範は喫煙者に制約を与えます。もしくは「煙草は体に悪い」という言
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTfulなビジネス対話