質問

現在、5ページほどの非常にシンプルなウェブサイトを作成しています。問題は、それが過剰であり、何らかのデータベース マッピング ソリューションを統合するのに時間を費やす価値があるのか​​、それとも単純に古い JNDI を使用する方が良いのかということです。データベースから読み書きする必要があるものはおそらく十数個あるでしょう。これらのテクノロジーについては基本的に理解していると思いますが、それでもドキュメントを参照するのに多くの時間がかかります。以前に決断を迫られた人はいますか?

編集:申し訳ありませんが、DB 接続を検索するために JNDI を指定し、操作を実行するために JDBC を指定する必要がありました。

役に立ちましたか?

解決

短い答え:それはサポートしたい複雑さによって異なります。

長い答え:

まず第一に、ORM (オブジェクト リレーショナル マッピング、いわゆるデータベース マッピング) と JNDI (Java Naming and Directory Interfaces) は 2 つの異なるものです。

1 つ目は、すでにご存知のとおり、データベース テーブルをクラスとオブジェクトにマップするために使用されます。2 つ目は、リソース (DataSource、Ejb、Queue など) の検索メカニズムを提供することです。

おそらく「JDBC」のことを指します。

さて、あなたの質問についてですが、それが単純であれば、ORM を実装する必要はないかもしれません。数表はせいぜい5~10程度で、操作は至って簡単だと思います。

おそらくプレーンな JDBC を使用するだけで十分でしょう。

DAO パターンを使用する場合は、必要に応じて ORM 戦略をサポートするために後で変更できます。

このような:Employee テーブルがあるとします。

DB のすべてのフィールドを含む Employee.java を手動で作成し (それほど時間はかかりません)、次のようなメソッドを使用して EmployeeDaO.java を作成します。

+findById( id ): Employee
+insert( Employee ) 
+update( Employee )
+delete( Employee ) 
+findAll():List<Employee>

そして実装は非常に簡単です。

select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc 

アプリケーションが複雑になりすぎた場合、DAO の実装を変更することがあります。たとえば、「select」メソッドでは、操作を実行する ORM オブジェクトを使用するようにコードを変更します。

public Employee selectById( int id ) {
      // Commenting out the previous implementation...
      // String query = select * from employee where id = ? 
      // execute( query )  

      // Using the ORM solution

       Session session = getSession();
       Employee e = ( Employee ) session.get( Employee.clas, id );
       return e;
}

これは単なる例であり、実際には、abstact ファクトリに ORM DAO を作成させることもできますが、それは本題から外れます。重要なのは、簡単に始めて、設計パターンを使用することで、必要に応じて後で実装を変更できるということです。

もちろん、テクノロジーを学びたい場合は、1 つのテーブルからすぐに始めることもできます。

どちらを選択するか (ORM ソリューション)、基本的には使用しているテクノロジによって異なります。たとえば、JBoss やその他のオープンソース製品の場合、Hibernate は優れています。これはオープンソースであり、学ぶべきリソースがたくさんあります。ただし、既に Toplink を備えたもの (Oracle アプリケーション サーバーなど) を使用している場合、またはベースが既に Toplink 上に構築されている場合は、そのフレームワークを使用し続ける必要があります。

ちなみに、Oracle が BEA を買収して以来、現在「Oracle Weblogic Application Server」と呼ばれているバージョンで、Kodo ( weblogic peresistence Framework ) を toplink に置き換えているとのことです。

これに関する詳細情報を入手できるリソースをいくつか残しておきます。


この「エンタープライズ アプリケーション アーキテクチャのパターン」の本では、Martin Fowler がどこでこれらを使用するかを説明しています。カタログは次のとおりです。データ ソース アーキテクチャ パターンとデータ ソース アーキテクチャ パターンを比較してみましょう。オブジェクトリレーショナルの行動パターン:

PEAAカタログ


DAO ( Data Access Object ) は、コア J2EE パターン カタログの一部です。

DAOパターン


これは Hibernate のスターター チュートリアルです。

休止状態


トップリンクの公式ページ:

トップリンク


最後に、JPA の良い考えは、最近プロバイダーを変更する可能性があることだと「思います」。

シンプルに始めて、その後進化させましょう。

これがお役に立てば幸いです。

他のヒント

非常に単純なアプリケーションにとっては、特にそれを拡張する計画がない場合には、やりすぎのように思えます。ただし、これらをこの単純なアプリケーションで使用して、次回それらを使用できるものがあるときにそれらがどのように機能するかをよりよく理解することも価値があるように思えます。

普通の古い JDBC のことですか?特に時間があれば、小規模なプロジェクトは ORM フレームワークの 1 つを手に入れる良い機会になるかもしれません。

ただし、より多くの情報がなければ、何らかの形で推奨事項を提供することは困難です。

私の経験則では、読み取り専用の場合は JDBC で実行しますが、Hibernate の型マッピングを利用するために SQLQuery で空の Hibernate プロジェクトを使用することを好みます。書き込みを行う必要がある場合は、Hibernate を使用します。これは、各列を個別に設定するよりも、いくつかの属性を設定してから save を呼び出す方がはるかに簡単であるためです。また、変更されていないオブジェクトの更新を避けるために最適化を開始する必要がある場合は、OR/M とそのダーティ チェックを使用する方がはるかに優れています。外部キー関係の処理は、一度マッピングしてからゲッターを使用する必要があることを示すもう 1 つの兆候です。同じロジックが Toplink にも当てはまりますが、私が使用してから 3 年間に HQL のようなものが追加されていない限り、純粋な SQL からのこの種の移行には Hibernate の方がはるかに優れています。すべてのオブジェクト/テーブルをマップする必要はなく、明確な利点があるオブジェクト/テーブルのみをマップする必要があることに注意してください。私の経験では、既存の OR/M を使用しないプロジェクトのほとんどは、最終的に新しい OR/M を構築することになりますが、これは悪い考えです。

最高 ORM を学ぶ方法は、小さなプロジェクトにあります。このプロジェクトを始めましょう。

コツを掴めば、あらゆることに ORM を使用できるようになります。

ORM にとって小さすぎるものはありません。最初のいくつかのプロジェクトを終えると、他の方法では作業できないことがわかるでしょう。ORM マッピングは通常、他のほとんどの作業方法よりも合理的です。

ここでさまざまなトップリンク ガイドを参照してください。イントロ、例、シナリオなどが含まれています。

http://docs.oracle.com/cd/E14571_01/web.1111/b32441/toc.htm

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top