3

マスター/ディテール設定でエンティティの作成と編集を処理するために、人々がどのような戦略を使用しているのか疑問に思っています。(私たちのアプリは、インターネット対応のデスクトップ アプリです。)

現在これを処理する方法は次のとおりです。編集が必要なエンティティのポップアップでフォームが作成され、オブジェクトのコピーが提供されます。ユーザーが「キャンセル」ボタンをクリックすると、ウィンドウを閉じてオブジェクトを完全に無視します。ユーザーが [OK] ボタンをクリックすると、マスター ビューに通知され、編集されたエンティティが受信されます。次に、originalEntity.copyFrom(modifiedEntity) を使用して、変更されたエンティティのプロパティを元のエンティティにコピーします。新しいエンティティを作成する場合は、空のエンティティをポップアップに渡します。ユーザーはそれを既存のエンティティであるかのように編集できます。マスター ビューは、受け取ったエンティティを管理するコレクションに "挿入" するか "更新" するかを決定する必要があります。

上記のワークフローについて、いくつか質問と意見があります。

  • エンティティのコピーの作成は誰が処理する必要がありますか? (マスターまたは詳細)
  • copyFrom() を使用して、参照が壊れる原因となるコレクション内のエンティティを置換する必要がないようにします。これを行うより良い方法はありますか？(copyFrom() の実装は難しい場合があります)
  • 新しいエンティティは -1 の ID を受け取ります (サーバー層/休止状態が挿入または更新を区別するために使用します)。これにより、(キャッシュされた) エンティティを保存する前に ID で検索するときに問題が発生する可能性があります。代わりに、新しいエンティティごとに一時的な一意の ID を使用する必要がありますか?

誰でもヒントやコツ、または経験を共有できますか? ありがとう！

編集：この質問には絶対的な間違いや正しい答えがないことを知っているので、マスター/詳細の状況を処理する方法について考えや長所/短所を共有できる人を探しています。

4

3 に答える 3

1

There are a number of ways you could alter this approach. Keep in mind that no solution can really be "wrong" per se. It all depends on the details of your situation. Here's one way to skin the cat.

who should handle the creation of the copy of the entity? (master or detail)

I see the master as an in-memory list representation of a subset of persisted entities. I would allow the master to handle any changes to its list. The list itself could be a custom collection. Use an ItemChanged event to fire a notification to the master that an item has been updated and needs to be persisted. Fire a NewItem event to notify the master of an insert.

we use copyFrom() to prevent having to replace entities in a collection which could cause references to break. Is there a better way to do this? (implementing copyFrom() can be tricky)

Instead of using copyFrom(), I would pass the existing reference to the details popup. If you're using an enumerable collection to store the master list, you can pass the object returned from list[index] to the details window. The reference itself will be altered so there's no need to use any kind of Replace method on the list. When OK is pressed, fire that ItemChanged event. You can even pass the index so it knows which object to update.

new entities receive an id of -1 (which the server tier/hibernate uses to differentiate between an insert or an update). This could potentially cause problems when looking up (cached) entities by id before they are saved. Should we use a temporary unique id for each new entity instead?

Are changes not immediately persisted? Use a Hibernate Session with the Unit of Work pattern to determine what's being inserted and what's being updated. There are more examples of Unit of Work out there. You might have to check out some blog posts by the .NET community if there's not much on the Java end. The concept is the same animal either way.

Hope this helps!

于 2009-06-23T12:47:35.017 に答える
0

CSLAライブラリは、この状況に大いに役立ちます。

ただし、自己実装したい場合：

マスターオブジェクトがあり、マスターオブジェクトには子オブジェクトのリストが含まれています。

詳細フォームは、子オブジェクトを直接編集できます。すべてが参照型であるため、マスターオブジェクトは自動的に更新されます。

問題は、マスターオブジェクトがダーティであるため、データベースなどに永続化する必要があることを認識していることです。

CSLAは、IsDirty（）プロパティを使用してこれを処理します。マスターオブジェクトでは、各子オブジェクトにクエリを実行して、ダーティであるかどうかを確認し、ダーティである場合はすべてを永続化します（マスターオブジェクト自体がダーティであるかどうかを追跡します）。

これはINotifyPropertyChangedインターフェイスでも処理できます。

あなたの他の質問のいくつかについて：

ロジックを分離したい。エンティティは、独自のプロパティのストレージとそれ自体の整合性ルールを処理できますが、異なるオブジェクトが相互に作用する方法のロジックは分離する必要があります。MVCやMVPなどのパターンを調べます。

この場合、新しい子オブジェクトの作成は、マスターオブジェクト内にあるか、子を作成してから親に追加する別のビジネスロジックオブジェクト内にある必要があります。

IDの場合、GUIDをIDとして使用すると、データベースと通信して正しいIDを判別する必要がないため、かなりの問題を回避できます。オブジェクトにフラグを付けて、それが新しいかどうかを確認できます（したがって、挿入または更新する必要があります）。

繰り返しになりますが、CSLAはこれらすべてを処理しますが、かなりのオーバーヘッドがあります。

キャンセル時の取り消しについて：CSLAにはnレベルの取り消しが実装されていますが、手動で実行しようとしている場合は、CopyFrom関数を使用するか、キャンセル時に永続層からオブジェクトのデータを更新します（再フェッチ）。

于 2009-07-02T03:06:51.953 に答える
0

私はそのようなモデルを実装しましたが、NH を使用していません。独自のコードを使用して、Oracle Db でオブジェクトを永続化しています。

同じ Web フォームでマスター詳細の概念を使用しました。

マスターエンティティグリッドがあり、詳細アクションコマンドで、クリックしたマスターレコード行のすぐ下にペナルティを開きます。

詳細追加モードでは、id が静的フィールドによって負の数で生成された空のエンティティを入力するだけです。[詳細を保存] ボタンで、そのエンティティを Asp.NET セッションのマスター レコードの詳細リストに保存しました。

詳細編集、表示で、Jqueryを使用してajax呼び出しを介して選択した詳細を詳細パネルに入力し、クリックした行のすぐ下にそのペナルティを追加しました。

[保存] ボタンで、マスター セッション (詳細のリストを含む) をデータベースに永続化しました。

そして、マスターが複数の詳細を記入する必要があるかのように、私はうまくいきました。

また、必要に応じて、行の下に追加する代わりに、Jquery Modal を使用してそのパネルをポップアップすることもできます。

それが役立つことを願っています:)ありがとう、

于 2010-01-19T19:08:19.927 に答える