1

現在、JCR (Modeshape) でテストアプリを実行しています。

  • 抽象化されたフローは次のとおりです。

  • 結果のノードには、ビューに表示する必要があるプロパティなどが含まれています。私は現在、ビューが jcrNode から直接プロパティを取得できるようにする単純なセットアップを行っています。ただし、これにより次のようなエラーが発生します。

一般的なアプローチ (そうでない場合は修正してください) は、セッションがまだアクティブなときに jcrNode によって入力されるある種の nodeDTO を作成することだと思います。その後、ビューは nodeDTO を自由に使用できるようになります。

さて、このような nodeDTO の完全な構造は、1 対 1 の jcrNode の構造を模倣するので、jcrNode を DTO 自体として使用してみませんか? これは、休止状態のデタッチ/アタッチに似た方法で実現できます。jcrNode (およびその子) には大量のデータが含まれている可能性があるため、分離の深さなどを決定するためのパラメーターがいくつかあるはずです。

別のアプローチは、mvc-framework 固有ですが、openSessionInView-pattern のようなものを使用することです。

したがって、これに対するいくつかのアプローチを見ることができますが、最初に最善のアプローチをとります(imo):

  1. jcrNodes のデタッチ/アタッチ機能
  2. DTO を作成するヘルパー クラスの優れたライブラリ
  3. openSessionInView

「ベストプラクティス」アプローチなどに関するコメントは大歓迎です。

4

2 に答える 2

2

Unfortunately, the JCR 2.0 specification does not define a way for the nodes to be detached from a session, so this kind of functionality would be implementation-specific.

In lieu of a JCR method, the only technique that is agnostic of a JCR implementation would be to copy the properties and child references in a very simple structure of your own creation. Yes, that structure would at a high-level be very similar to a JCR node, but it wouldn't need to have 90% of the methods defined on Node: a simple map of properties (by name), and a list (or ordered map) of child nodes. And by doing this, your code would be responsible for copying the nodes and subgraphs you're interested in, so you can define the semantics to suit your needs.

However, as the project lead for ModeShape, I do agree that detaching JCR nodes does seem like a good feature, and so I've logged it as an enhancement request in the ModeShape project. There are a lot of details to work out in terms of the proper semantics (especially relating to child or descendant nodes), so I'd invite you to watch that request and participate in the discussion on that issue.

于 2011-07-21T17:13:58.180 に答える
0

Modeshape-in​​-JBoss の上に JBoss Seam Web アプリケーションを開発しています。最初は私も DTO アプローチを使用していましたが、それを放棄しました。代わりに、Seam 会話またはサーブレット セッション全体のいずれかに対して、JCR セッションを開いたままにしておく方が簡単でした。

Seam を使用していない場合は、会話の代わりにサーブレット リクエスト スコープに同様のアプローチを使用できます。

私はまだ本番環境ではなく初期開発段階にあるため、これが「ベスト プラクティス」であるとは言えません。ただし、これまでのところ、どちらも実行可能なアプローチのようであり、問​​題はありませんでした。

まず、login() に使用される JCR リポジトリ (ServiceLoader を使用) を作成する Application スコープの Seam Manager コンポーネント (@Unwrap を使用) を用意します。

次に、セッションの場合:

  1. 会話スコープの JCR セッション: JCR セッションを会話スコープに配置する変換スコープの Seam マネージャー コンポーネントを作成しました。Seam コンポーネントは作成時に repository.login() を実行し、会話の最後でコンポーネントが破棄されると session.logout() を実行します。これは本質的に、Seam アプリで通常使用される会話スコープの JPA EntityManager と同じアプローチです。

  2. セッション スコープの JCR セッション: Seam (サーブレット) セッション スコープ以外は上記と同じです。これにより、明らかに JCR セッションが長時間 (場合によっては数時間) 開かれます。これに落とし穴があるかどうかはわかりませんが、これまでのところ、これがより自然なアプローチのようです。

どちらの場合も、アプリケーション コードは、更新を行った後に session.save() を実行します。

ただし、ある種のセッションレス DTO ユーティリティ API が非常に役立つという点には同意します。これは、EJB を使用して JCR 機能をクライアントに公開している場合に明らかになります。EJB はシリアル化可能なデータ オブジェクトのみを渡すことができるため、JCR ノードとプロパティおよび値を直接渡すことはできません。JBoss で実行されている同じ Modeshape リポジトリにアクセスする必要がある Eclipse RCP アプリケーション (Web アプリケーションのコンパニオン) を開発しているときに、この状況に遭遇しました。最終的には、Randall が推奨したことと非常によく似た作業を行うことになりました。単純なシリアル化可能な NodeDTO および PropertyDTO オブジェクトを開発し、JCR ノードおよびプロパティからそれらを作成するためのいくつかのユーティリティ メソッドを用意しました。Modeshape または JCR がこれらのユーティリティを提供して、リポジトリへのクライアント サーバー アクセスを支援できるとしたら、それは素晴らしいことです。

于 2011-07-22T18:01:13.803 に答える