AgileData.org in Japanese - オブジェクト・リレーショナル・インピーダンス・ミスマッチ
http://www.agiledata.org/essays/impedanceMismatch.html この論文は、Agile Database Techniques Chapter 7より抜粋。 オブジェクト指向技術はデータと振る舞いを持つオブジェクトを使ったアプリケーションの構築をサポートする。リレーショナル技術はテーブルへのデータの保管をサポートする。また、データベース内部においてはストアドプロシージャ、外部からはSQL呼び出しを用い、データ操作言語（DML; Data Manipulation Language）を使ったデータの操作をサポートする。 さらに進歩したリレーショナル・データベースには、内部的にオブジェクトサポートするようなものもある。 データベースがより強力になるというこの傾向は、時とともに強まりこそすれ弱まることはないだろう。 多くの組織において、オブジェクト
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
PofEAA's Wiki - DataMapper
原文: http://www.martinfowler.com/eaaCatalog/dataMapper.html Mapper (473) レイヤは、オブジェクトとデータベース間でデータを移動させる。データは、オブジェクト、データベース、およびMapperから独立させる。 解説の全文は『PofEAA』 165 ページを参照。 オブジェクトとリレーショナルデータベースは、 異なるメカニズムでデータを構成している。 オブジェクトの多くの部分（コレクションや継承など）は、 リレーショナルデータベースでは表すことができない。 多くのビジネスロジックを伴ったオブジェクトモデルを構築する場合、 データおよびデータに付随する振る舞いをうまくまとめるために、 このメカニズムを使うことは非常に大切である。 これによりスキーマが異なったままとなる。 つまり、オブジェクトスキーマとリレーショナルスキーマは
Martin Fowler's Bliki in Japanese - Junit新インスタンス
http://martinfowler.com/bliki/JunitNewInstance.html JUnit testing framework のあるデザインについて、よく質問を受ける。 テストメソッドを走らせるたびに、新しいオブジェクトができる点についてだ。 blikiへ投稿するに値する内容だと思ったのでここに記す。 （ 念のために言っておくが、JUnitについて何か書くからといって、 その他のテストのやり方が重要じゃないと思っているわけじゃないですから。 有益なテスト方法はたくさんあるわけで、 JUnit やその親戚（xUnit）がいくら便利だからって、 すべてを解決してくれるわけじゃない。 テストについて言及してるblogがいくつかあるから、 そちらを読んでみることをお勧めする （ Brett Pettichord, Brian Marick, James Bach ）。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AgileData.org in Japanese - データモデルとオブジェクトモデルの相違
