http://www.martinfowler.com/bliki/EnterpriseRails.html Railsのコミュニティでは「エンタープライズ」という言葉がダーティーワードになりつつある。 多くの人にとってRailsフレームワークとは、貪欲にシンプルさを備えたものであり、複雑になり過ぎた「エンタープライジー」なフレームワークへのアンチテーゼなのだ。 先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。 その中にはエンタープライジーなことも含まれていた。 たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。 これに対するDHHの反応は、この上なく痛烈な拒絶であった。Wired誌*1の表紙になった画像をうまく編集して、DHHは自らをソフトウェア界のネオ（救世主）として
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
