1

私のWinFormsアプリケーションにビジネス エンティティ Order があり、エンティティが複数のビューで使用され、各ビューがアプリケーション内の異なるドメインまたはユース ケースを処理するとします。例として、1 つは注文を管理し、もう 1 つは 1 つの注文を掘り下げて追加データを表示します。

nHibernate (またはその他の ORM) を使用し、ビューごと (または db アクションごと) に 1 つの session/dataContext を使用すると、同じ Order (orderId = 1 としましょう) に対して 2 つの異なるインスタンスを取得することになります。機能的には同じエンティティですが、技術的には 2 つの異なるインスタンスです。はい、Equals/GetHashcode を実装して、同じように「見える」ようにすることができます。

エンティティごとに 1 つのインスタンスを使用するのに対して、ビューごとまたはユースケースごとにプライベート インスタンスを使用する理由は何ですか?

単一のインスタンスを持つことには、INotifyPropertyChanged イベントを共有し、追加の (非永続的な) データを共有するという利点があります。

各ビューにプライベート インスタンスがあると、ビュー レベルで元に戻す機能の柔軟性が得られます。上記の例では、ユーザーが注文の詳細を変更できるようにし、変更を保存しないという柔軟性をユーザーに与えます。ここでは、ビュー/ユースケース間の同期がデータの永続性レベルで発生します。

あなたの主張は何ですか？

4

2 に答える 2

2

/メソッドを実装する必要があります。これは、ORM を使用する場合に推奨される方法です。EqualsGetHashCode

さらに、通常は「1 つのビュー、1 つのセッション」というマントラに固執する必要があります。ビューが変更されたり、フォーカスが失われたりしても、すべてのオブジェクトを永続化します。ビュー間でエンティティを本当に共有する必要がある場合は、そうしてください。時々あなたはしなければなりません。

繰り返しになりますが、ビジネス オブジェクトをエンティティと行タイプの観点から見ている場合、「オブジェクト」レベルの等価性は気にする必要はありません。

于 2010-03-16T21:21:41.073 に答える
0

私は ORM について話すことはできませんが、あなたは自分の質問にある程度答えたと思います。両方のオプションの長所と短所を提供しました。どちらも絶対的に正しいか間違っているわけではありません。

オプションは、状況に応じて正しいか間違っているだけです。情報を共有することが理にかなっている場合は、単一の共有インスタンスを使用しますが、元に戻す機能がより重要な場合は、複数の/プライベート インスタンスを使用します。

決定を下す他の懸念事項もあるかもしれません。NFR (または「病気」) とシステムのコンテキストについて考えてみてください。たとえば、パフォーマンスが重要な問題であり、大規模なユーザー ベースが必要であることがわかっている場合は、どちらか一方のオプションを提案するのに役立つか、最初から再考する必要があるかもしれません。

最後に - 「秩序」がありますが、他のエンティティはどうですか - それらはどのように処理されていますか?
または、持っていない場合は、いつ/持っていればどうなりますか? それはあなたのアーキテクチャに影響を与えますか?

于 2010-03-17T03:28:57.683 に答える