問題タブ [persistence]

概要:永続的な Java Web アプリケーションを開発しています。重複を防ぐために、永続化するすべてのリソースにグローバルに一意の識別子があることを確認する必要があります。

ファインプリント：

1. 私は RDBMS を使用していないので、派手なシーケンス ジェネレータ (Oracle が提供するものなど) を持っていません。
2. 高速で、できればすべてメモリ内にあることを望みます-ファイルを開いて値をインクリメントする必要はありません
3. スレッドセーフである必要があります (一度に 1 つの JVM だけが ID を生成する必要があると予想しています)。
4. JVM のインスタンス化全体で一貫性が必要です。サーバーがシャットダウンして起動した場合、ID ジェネレーターは以前のインスタンス化で生成したものと同じ ID を再生成するべきではありません (または、少なくとも可能性は非常に低くなければなりません - 何百万もの既存のリソースが予想されます)。
5. EJB 固有 ID パターンの記事で例を見てきました。それらは私にはうまくいきません (ミリ秒ごとに複数のリソースを永続化するため、System.currentTimeMillis() だけに依存したくありません)。
6. この質問で提案されている回答を見てきました。それらについての私の懸念は、時間の経過とともに重複した ID を取得する可能性はどのくらいかということです。UUIDにjava.util.UUIDを使用するという提案に興味をそそられましたが、繰り返しになりますが、重複の可能性は限りなく小さくする必要があります。
7. 私はJDK6を使用しています

バイナリ ファイルと RDBMS の両方にクラス インスタンス データを読み書きするための機能またはフレームワーク (つまり、インターフェイス クラスなど) を提供する C++ ドメイン モデル クラス ライブラリを開発しています。このライブラリの基礎は、RDBMS を使用するアプリケーションです。データベースの取得と更新の一連の呼び出しを実行してメンバー データのコレクションを取得することにより、クラスをインスタンス化するメソッドがいくつかあります。シリアル化されたデータ アクセスでは、データを整理する方法が異なるため、ドメイン モデルがプライマリ/外部キー、ID などを完全に認識しないようにする必要があります。

この問題を解決するために、私はデータ アクセス オブジェクト(DAO) パターンの使用を検討しており、DAO オブジェクトの「粒度」、有効期間、および使用についてアドバイスをお願いしたいと思います (返信では、C++ を使用することに注意してください)。であり、ドメイン クラスは RDBMS またはバイナリ ファイル ストアからの ID/キー情報を保持できない):

1. ドメイン オブジェクトの各 Foo インスタンスには独自の FooDAO インスタンスがありますか、それともクラス Foo のすべてのインスタンスに対して単一の FooDAO インスタンスがありますか?
2. FooDAO は Foo インスタンスごとに 1 回作成されますか?それとも、FooDAO インスタンスはデータへのアクセスが必要な場合にのみ作成され、その後すぐに破棄されますか?
3. DAOのJ2EEページでは、DAO に加えて DTO を紹介しています。DAO がデータを転送できないのはなぜですか?
4. 他のドメイン クラス Bar のインスタンスを持つ複雑なドメイン クラス Foo の場合、FooDAO クラスが BarDAO クラスを使用してデータを取得することは避けられないようです。これは、ドメイン クラス構造と DAO クラス構造に並列の階層/依存関係をもたらします。これをどのように管理するのが最善でしょうか?

ご協力いただきありがとうございます！

データベースにアクセスするための最良の戦略を決定しようとしています。これは一般的な質問であり、唯一の適切な答えがないことは理解していますが、探しているものに関するガイドラインをいくつか提供します。ここ数年、私たちは独自の永続化フレームワークを使用してきましたが、これも限定的ではありますが同様に機能しています。ただし、いくつかの大きな改善が必要であり、そのようにするか、既存のフレームワークのいずれかを使用する必要があるかどうか疑問に思っています。私が探している基準は、重要な順に次のとおりです。

1. クライアント コードは、データベースの知識がなくても、クリーンなオブジェクトで動作する必要があります。カスタム フレームワークを使用する場合、クライアント コードは次のようになります。

   SessionManager セッション = 新しい SessionManager(); オーダー order = session.CreateEntity(); order.Date = DateTime.Now; // その他のプロパティを設定します OrderDetail detail = order.AddOrderDetail(); detail.Product = 製品; // その他のプロパティ

   // 今すぐすべての変更をコミットします session.Commit();

2. できるだけシンプルで、「柔軟性がありすぎない」必要があります。ほとんどのことを行うには、単一の方法が必要です。

3. オブジェクト指向プログラミングを適切にサポートする必要があります。1 対多および多対多の関係を処理し、継承を処理し、遅延読み込みをサポートする必要があります。
4. 構成は、XML ベースであることが望ましいです。

私の現在の知識では、次のオプションがあります。

1. 現在のフレームワークを改善する - 問題は、かなりの労力が必要なことです。
2. ADO.NET Entity Framework - よく理解していませんが、複雑すぎてレビューが悪いようです。
3. LINQ to SQL - オブジェクト指向のプラクティスを適切に処理できません。
4. nHibernate - 良いオプションのようですが、古いエラーが多すぎると報告するユーザーもいます。
5. SubSonic - 簡単な紹介からすると、柔軟性が高すぎるように思えます。私はそれを望んでいません。

何を提案しますか？

編集：

精巧な答えをありがとうクレイグ。カスタム フレームワークについて詳しく説明すると、さらに役立つと思います。似たようなものを探しています。カスタム フレームワークの仕組みは次のとおりです。

1. これは DataSet に基づいているため、最初に DataSet を構成し、そこに必要なクエリを記述します。
2. DataSet テーブルをオブジェクトにマップする方法を指定し、それらの間の関連付けも指定する XML 構成ファイルを作成します (すべての種類の関連付けをサポートします)。3. カスタム ツールが XML 構成を解析し、必要なコードを生成します。4.生成されたクラスは、共通の基本クラスから継承します。

フレームワークと互換性を持たせるには、データベースが次の基準を満たしている必要があります。

1. 各テーブルには、主キーとして 1 つの列が必要です。
2. すべてのテーブルには、クライアントで生成された同じデータ型の主キーが必要です。
3. 継承を処理するために、単一テーブルの継承のみがサポートされています。また、XML ファイルは、ほとんどの場合、何かを達成するための単一の方法を提供します。

私たちが今サポートしたいのは：

• DataSet から依存関係を削除します。SQL コードは自動的に生成されますが、フレームワークはスキーマを生成しません。DB スキーマを手動で制御したい。
• 継承階層のより強力なサポート。
• オプションの LINQ との統合。

私が探しているものがより明確になったことを願っています。

ユーザーが情報をファイルに保存して後で復元できるように、アプリケーションのインスタンス間の一種の交換フォーマットを開発しています。「交換フォーマット」全体は、シリアル化されてディスクに書き込まれる単一のクラスです。

そのクラス内にグラフィック/サウンド情報を保存するにはどうすればよいですか? ファイルを.jarに入れるだけは避けたいです。

私は LINQ to SQL で少し遊んでいますが、全体的には Microsoft が以前に持っていたもの (DataSet) よりもはるかに優れたオプションですが、オブジェクト指向の機能はまだ制限されているようです。現在、DataSet の上に OO モデルを作成するカスタム永続化フレームワークを使用しているため、LINQ to SQL の上に OO モデルを構築する新しいバージョンにフレームワークを移植することを検討しています。

1. まず、他に同様の取り組みはありますか？
2. 第二に、この道を行くのは良い考えだと思いますか?

自家製の永続化フレームワークを JPA に移行し始めたところです。

永続化フレームワークが多くの配管を隠していることを考えると、EntityManagers を閉じないとリソース リークが発生するかどうか、またはフレームワークがそれらを収集して閉じるかどうかを知りたいと思っています。

私はすべての場所でそれらを閉鎖するつもりですが、そうしなければなりませんか?

現時点では、NetBeans で簡単に動作するという理由だけで TopLink を使用していますが、喜んで他の JPA プロバイダーを調査します。

Object Prevalance メカニズムは実際の本番システムで使用されていますか? PrevaylerやMadeleineのようなものを指しています

私が見つけた唯一のものは、Wiki エンジンのInstikiです。しかし、彼らが始めて以来、彼らは SQLite に切り替えました。(実際のinstikiのページはダウンしています)

YAML は、構成ファイルと、人間が読める形式の永続オブジェクトをデータ バインディングするための優れた形式のようです...

YAML を処理する C++ ライブラリはありますか? Boost::Serialization には YAML オプションの計画がありますか?

編集: オブジェクト指向ライブラリを好むでしょう。

hibernate.generate_statistics=true を設定し、mbeans を登録して、jmx コンソールで統計を確認できるようにする必要があります。どこにもたどり着けないようで、これはそれほど難しい問題ではないようです。多分私は物事を複雑にしすぎているのかもしれませんが、いずれにせよこれまでに私は試しました:

• EhCacheProvider をコピーし、初期化後に init() をオーバーロードして ManagementService.registerMBeans(...) を呼び出す CacheManager の拡張バージョンをインスタンス化しました。registerMBeans(...) への実際の呼び出しまで、コードはすべて正常に実行されました。これにより、プロバイダーの初期化が一般的なエラーで失敗します (残念ながら、書き留めていませんでした)。このアプローチは、このライフレイで使用されるメソッドによって動機付けられました。パフォーマンスのウォークスルー。
• ehcache の jmx mbeans を登録するこの例と同様のコードを実行する start メソッドを使用して、独自の MBean を作成しました。すべてが正しく動作しているように見え、mbean は jmx コンソールに表示されますが、net.sf.ehcache には何も表示されません。
• それ以来、ehcache を 1.5 にアップグレードし (1.3 を使用していましたが、それが jboss 4.2.1 に固有のものなのか、自分で選択したものなのかはわかりません)、SingletonEhCacheProvider を使用するように変更し、手動で統計を取得しようとしました。 mbean 登録。ただし、実際には改善されていません。getInstance() を呼び出すと、返される CacheManager には StandardQueryCache のコピーしかありませんが、jboss ログには、他の多くのキャッシュが初期化されていることが示されます (アプリケーション内のキャッシュされたエンティティごとに 1 つ)。

編集：まあ、私は1つのことを理解しました... JConsoleを介して接続すると、統計mbeansが明らかになります。ManagementFactory.getPlatformMBeanServer() は、jboss が使用しているのと同じ mbean サーバーを提供しないと思います。とにかく、統計を手動で収集しようとしたときと同様の問題が発生しているようです。アプリを少しクリックした後でもすべてゼロになるためです。

NHibernate を使用して列挙型を DB に永続化する方法はありますか? つまり、列挙型の各値のコードと名前の両方のテーブルがあります。

エンティティなしで列挙型を保持したいが、他のすべての参照エンティティから列挙型のテーブルへの外部キー (列挙型の int 表現) を保持したい。