O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して
一般的な業務アプリケーションではデータを永続化するために、RDBMS（関係データベース管理システム）を利用します。RDBMSでは大量のデータを効率的に検索したり、集約してレポートを作ったりすることが得意ですし、一般的に業務システムで求められるトランザクションのACID特性*1を満たすことも容易です。また、適切にテーブル設計の正規化を行うことにより、運用面においてデータの管理コストを下げることもできます。最近ではスケーラビリティの問題などもあり、RDBMS以外のデータベースについても注目されるようになってきていますが、今後も業務アプリケーションの主流としてRDBMSは使われていくだろうと思われます。 従って、Javaなどのオブジェクト指向言語で開発を行い、DDDのようなオブジェクト指向の設計技法を利用する場合に必ず考えなくてはならない問題は、オブジェクト指向と関係モデルとのインピーダンスダン
ORマッパーならDomaが一番。 - newta(にゅーた)の日記
すっかり明けてますね。 まあ、夏くらいから更新してないですが。。 ともかく、今年もよろしくお願いします。 で、Domaなんですけど、 実践投入すごくしてます。いっぱい使ってます。感謝。 今のところ、ORマッパーを使うならDomaが一番の選択肢です。 理由 印象はS2Daoのようで、 S2Daoよりサポートしている部分でかゆいところに手が届いてる感じ。 selectは外だしSQLのみにすることで実行されるSQLが分かりやすく 定義箇所がsqlテンプレートファイルのみなので管理しやすい。 SQLテンプレートはSQLコメント内に設定構文を書くので SQLをそのまま実行して試すことが出来る。 aptによるチェックで、sqlテンプレートと条件やvalueの定義に 間違いがある場合、すぐに分かる。これとっても重要。 S2Dao使ってたら実行しないと分からない事がすぐ分かる。 条件のプロパティの定義忘れ
O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
