0

un DBを使用し、このモードで構造化されたアプリケーションを開発する必要があります。

  1. メタデータテーブル（ドキュメントタイプ、ドキュメント属性...）があります
  2. メタデータテーブルから開始して、メタデータテーブルが作成/変更されます（実行時の通常のアプリケーションライフサイクル中も）。

IE：新しいドキュメントタイプを作成し、「ドキュメントタイプ」（契約、請求書、注など）という名前のMETADATAテーブルに新しいレコードを挿入すると、新しい相対DATAテーブルがDBに作成されます。このテーブルには、他のMETADATAテーブル（ドキュメント属性）で定義した属性が列として含まれています。

実行時に構造が変更されないため、METADATAテーブルをマップするためにORMを使用したいと思います。DATAテーブルもマッピングすることは可能ですか？データテーブルについてもPOJOを使用したいと思います。

実行時にクラスを作成して（リフレクションを使用することは可能ですが、最良の選択ですか？）、theyr構造を変更することは不可能だと思います。

これはおそらくCMSとCRMから使用されるロジック/問題です。

特にORM/DBの場合、アプリケーションを構造化する方法について何か提案はありますか？

ありがとうございました

4

2 に答える 2

0

JPAとeclipseLinkが私の選択かもしれません。

あなたは次のような立場にいます: 組織 (CMS) によってオンラインで編集可能なビジネス ロジック、たとえばルール エンジンを使用して開発された Web アプリケーション。非常に一般的で、いい音で、開発コストを削減します。ただし、変更をテストすることも、バージョン管理に入れることも、すぐに有効にすることもできません。デバッグなし、コンパイラ インテリジェンスとエラー メッセージなし、クリーンアップなし (コードのクリーンアップなど)。実際、このようなシステムは品質上のリスクが高く、メンテナンスの負担が大きくなります。

あなたの場合、非常に強力なツールが必要です: バージョン管理、独立したステージング サーバー、制御可能なロジック、レポート (モデルと相互作用の自動ドキュメント化)。

JPA は原則として、エンティティからデータベース テーブル自体を作成できます (またはその逆)。これが 1 つのレイヤーです。メタモデルを維持します。

メタモデルに由来するものなので、確かに何か賢いことをする必要があります。

最も簡単で達成可能なのは、メタ モデルだけにとどまり、バージョン管理などを定義することです。手動コードは、マップのような一般的なデータを使用します。コードをデータベースに保存してバージョン管理し、Java Scripting API を使用することもできます。しかし、経営陣に拡張を通知し、実現可能性を確信する必要があります-プロトタイプを作成します.

誰かがより良い解決策を知っていることを願っています。

PS

多分 NoSQL データベースは、ドキュメント DB に少し似ています。

于 2012-05-22T17:04:40.610 に答える
0

このような少ない情報で適切なアドバイスを提供することは困難です。ただし、「JCR」タグが含まれており、ユースケースがコンテンツまたはドキュメント管理システムに似ているように思われるため、JCR を検討する必要があります。「他のオプションよりも JCR を使用する場合は?」を参照してください。より一般的な回答ですが、特定のユースケースでの利点を説明しようと思います. (ただし、常にその仕事に最適なツールを選択してください。)

おそらく、JCR の最も優れた機能は、さまざまなドキュメントのメタデータを時間の経過とともに追加 (または変更) できる柔軟なスキーマを持つ機能です。プロパティを制限して、アプリが承認済みの情報のみを追加するようにするか、オプションを少し緩めて、必要に応じて追加のメタデータを追加するオプションを開いたままにすることができます。mixin を介して個々のノードに追加できる「特性」にメタデータを分割することもできます。要するに、JCR は、データ構造を設計する際に多くの柔軟性を提供すると同時に、使用する適用/柔軟性を制御するためのいくつかのノブを提供します。

JCR リポジトリを使用すると、そのメタデータをドキュメントと共に保持することもできます (必要に応じて、いつでも分離できます)。また、ドキュメントを読み取ってメタデータを取得するアクセス パターンをアプリケーションが使用する場合、アプリケーションのパフォーマンスが向上する可能性があります。多くの場合、ナビゲーションはクエリよりもはるかに高速です。

第 3 に、多くの JCR リポジトリは、(ノード タイプをリレーショナル テーブルのような構造にマッピングすることによって) リポジトリ コンテンツのクエリをサポートしています。JCR 2.0 には、XPath や「JCR-SQL2」と呼ばれる SQL に似た言語など、いくつかの言語があります。

JCR 用のオブジェクト マッピング ライブラリがいくつかありますが、それらは JCR のデータ構造の柔軟性を実際に利用するのを妨げる可能性が非常に高いです。JCR 自体は Java API であり、イベント、セキュリティ、クエリ、ロック、バージョン管理などのサポートが組み込まれています。

JCR を確認する場合は、JackrabbitやModeShapeなど、さまざまな実装を確認してください。それらはそれぞれ異なるものを提供します (たとえば、Jackrabbit は参照実装ですが、ModeShape はいくつかの拡張機能と、拡張されたクエリ言語やシーケンスなどの追加機能を提供します。この関連する質問を参照してください)。

于 2012-05-22T17:56:04.763 に答える