忍者ブログ
  • 2017.09
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 2017.11
JPAとは
JPAの特徴

・Persistent ContextにEntityを配置する。
・Persistent Contextはコミット時等にDBに反映される。

・JPQLを用いることができる。
 JPQLとはPersistent Contextを操作するSQLライク言語である。
  取得はテーブル単位で行うことが出来る。
  というか、テーブル単位のみ行うことが出来る。
  というか、テーブル単位のみでしか行うことが出来ない。

  これはどういうことかと言うとPersistent Contextに配置されるたものは
  どのQueryでも触れるため、Query1は列1、2だけ。
  Query2は列1、3だけなんてやってしまうと列単位で取っていないものは
  DBに再アクセスする必要がでてきてしまうからである。

  つまり、Persistent Contextはレコード単位でDBと同期が取られる。
  ※これは更新が全項目という意味ではない。更新は部分的。


・EntityManager API
  JPQLではなく、EntityManagerでもPersistent Context にアクセスすることができる。
  findは、Persistent Contextの該当するEntityをキーで取得する。
  Persistent ContextになければDBにアクセスする。
  DBにアクセスしないgetReferenceなんてものもあるが、Persistent Contextで
  検索前提とする使用方法っていまいち思いつかない。

  リレーションは1対Nの場合、get○○sとget○○で双方向にアクセスできる。
  しかし、Persistent Contextにない場合はSQLが発行される。

  また、自分でPersistent ContextにEntityを追加する場合、
  new したEntityをpersistすることで配置することができる。
  ただし、リレーションがある場合、自分で構築する必要がある。

  追加ばかりしてるとメモリが膨らむためclearをある程度で行う必要があるだろう。

結局のメリットは・・・
  find により、キー取得のDBアクセスメソッドを用意しなくてもいい。
  Persistent Contextによりメモリ内にあればDBアクセスしなくても良い。
  要注意:これが有効になるのって主キーを条件にしたときだけである!?
   たとえばキーとしてid、項目としてnameがある時、name="me"と
   検索してDBにアクセスしない条件は・・・DBの内容がすべて
   Persistent Contextにあることである。
   そんな前提が満たされる瞬間なんて起こり得ないよね・・・。

  複数テーブルを取得する時が便利!?
   Persistent ContextにはEntityごとに一意のインスタンスが生成される。
  よって例えば複数のテーブルを取得しようとしてもそれぞれのEntityが
  Persistent Contextに配置される過程においてマージされる。

  ・・・便利なのか!?
  オブジェクト指向とRDBをマッピングしたという点においては
  MicrosoftのDataSetと違ってよりオブジェクトライクになっているとは思う。
  しかし、Microsoftのストアドで複数テーブル返せることを考えれば
  net上に重複レコードが流れる分あまり洗練されていないようにも思える。
  もちろん別々に
  select c from Town t join t.city c where t.name like :name
  select t from Town t join t.city c where t.name like :name
  とすれば、レコード分しか流れないが
  だからどうしたといわれそう(笑)

デメリットは・・
  JDBCとの併用はできないというところ。
  なぜなら、JPAはもはやデータソースの設計ではない!
  アプリのメモリ設計である。
  ERでライフサイクルが違ってもキーが同じであればまとめることなんて
  ままあったけども、もはやJPAを採用した時点でこの設計は許されない。
  そう・・・一対一のLAZYを考えて設計する必要がある。
  これは、ログイン時にとりあえず、ユーザアカウントとパスワードで
  Webページを回る場合、その他の住所・連絡先・TEL等の詳細情報は
  ユーザアカウントという同じキーであってもテーブルを分ける作業が
  必須となってくる。
  じゃあ、1対1である時はAとB、BとC、AとCが欲しいときは
  それぞれリレーションをはるのだろうか・・・。
  いまいちよく分からない。

  また、もう一つ気をつけないといけないことは・・・
  更新したかったのかい?みたいな事が起こる気がする。

  だって、代入したら更新されるってSQL文は自由自在に作成されて
  今まで、親テーブル・子テーブル・孫テーブルを
  トランザクションかけてそそくさとやってたのが
  関数呼んだら実は中でいらってた・・デタッチされてたはずだったのに
  みたいなことが起こりそうな予感・・・。

  それらはcommitした瞬間に全て反映される。
  訳わかめな気がしないでもない。


総評
  JDBCのDBアクセスの記述方法が変わった程度で影響範囲を
  絞った上で発行されるSQLを意識して使用する必要があると思う。
  ビューに戻すときは確実にデタッチしたほうが良かったりするのかな?
  まぁ、とはいえ新しいものは面白いなぁと思う。
  こんな複雑な仕組みが標準として来ているところが時代が変わったのか
  なんなのかって思う。
  こんな凝った仕組み作ったらメンテできないからって
  怒られそうでとても業務で作ろうとは思わない・・・。
  でも、これが標準って言われたら皆使うんだよね。
  実際に業務で使わないとその力は計りしれないけど「面白い」に尽きる。
  良くも悪くも「面白い」。
  すぐに便利と決めつける人は後々苦労しそうなおもちゃだと思う。
PR
【2012/10/07 17:46 】 | java | 有り難いご意見(0)
                                    
<<構造化プログラミング | ホーム | マリオと放物線>>
有り難いご意見
貴重なご意見の投稿














<<前ページ | ホーム | 次ページ>>