7

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

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

4

6 に答える 6

17

簡単な答え: サポートしたい複雑さによって異なります。

長い答え:

まず、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;
}

これは単なる例です。実際には、抽象的なファクトリに ORM DAO を作成させることができますが、それはトピック外です。要点は、単純に始めて、設計パターンを使用することで、必要に応じて後で実装を変更できるということです。

もちろん、技術を習得したい場合は、テーブルが 1 つでもすぐに始めることができます。

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

ところで、Oracle は BEA を買収したため、現在は「Oracle Weblogic Application Server」と呼ばれる Kodo (weblogic 永続化フレームワーク) をトップリンクに置き換えているとのことです。

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

この「エンタープライズ アプリケーション アーキテクチャのパターン」の本で、Martin Fowler は、どちらを使用するかについて説明しています。カタログは次のとおりです。データ ソース アーキテクチャ パターンとオブジェクト リレーショナル動作パターンをご覧ください。

PEAAカタログ

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

DAO パターン

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

休止状態

Toplinkの公式ページ:

トップリンク

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

シンプルに始めて、次に進化させます。

これが役立つことを願っています。

于 2008-09-23T18:37:28.050 に答える
1

ORMを学ぶ最良の方法は、小さなプロジェクトです。このプロジェクトを開始します。

コツをつかんだら、すべてにORMを使用します。

ORMには小さすぎるものはありません。最初の数件のプロジェクトの後、他の方法で作業することはできません。ORMマッピングは、一般的に、他のほとんどの作業方法よりも理にかなっています。

于 2008-09-24T02:20:30.857 に答える
1

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

于 2008-09-23T18:10:16.370 に答える
1

昔ながらのJDBCのことですか？小さなプロジェクトは、特に時間があれば、ORMフレームワークの1つを選択する良い機会かもしれません。

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

于 2008-09-23T18:14:54.860 に答える
1

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

于 2008-09-23T21:36:08.497 に答える