Java Persistence API（JPA）を使ってオブジェクトの世界とリレーショナルの世界を結び付ける方法を一緒に学んでいきたいと考えています。前編では1つのテーブルに対してCRUD操作を行いました。後編となる今回は、複数のテーブル間の関連をEntityモデルで表現する方法と、それらを扱うためのJPQLについて説明します。 はじめに JPA（Java Persistence API）とは、オブジェクトの世界からリレーショナルの世界へ、あるいはその逆への変換を行うためのAPIです。 前編では、JPAを使用した1テーブルに対するCRUD操作を行うための実装方法を説明しました。後編となる今回は、複数のテーブルに対するCRUD操作について解説していきます。 ディレクションとカーディナリティのトラウマ オブジェクトモデルの世界でEntity間の関連は、ディレクションとカーディナリティという2
JPAとは JPA（Java Persistence API）とはオブジェクトの世界からリレーショナルの世界へ、あるいはその逆への変換を行うためのAPIです。 それでは何もJPAを使わずともHibernateやiBatisを既に使っているから必要ないのではと考えられた方も多いかと思います。確かに既にそれらのO/Rマッピングフレームワーク（以降、O/Rマッパー）を利用されているのであれば特に必要ないのかもしれません。 そう思った方も少し待ってください。データベース製品の多様性を隠ぺいするためにJDBCが考えられたように、あるいはMOM製品の多様性を隠ぺいするためにJMSというAPIが考えられました。ところがO/Rマッパーの違いを隠ぺいするためのAPIは存在しなかったのです。iBatisを使用されている方にはあまり嬉しくないかもしれませんが、JPAの仕様作成の中心人物こそHibernateプロ
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
