2

Yo-これはそれ自体がravendbの問題ではありません-一般的なドキュメントデータベースに関する別の設計上の質問です。

ですから、私はDenormalizedReferenceをかなり使用してきましたが、多くの場所でDDDがかなり難しくなっていることに気づきました。

たとえば、子コレクションを持つオブジェクトがあるとします。

 List<DenormalizedReference<SomeType>>

この子コレクションは、親がオーバーロードされたコンストラクターでインスタンス化され、List<SomeOtherType>

ここで、コンストラクターで、渡されたSomeOtherTypeコレクションからこのリストを作成したいと思います。つまり、SomeOtherTypeごとに新しいSomeTypeを作成する必要があります。

DocumentSessionをドメインに渡さないと（これは行いません）、親ARを保存すると、IdとNameを除く各子オブジェクトのプロパティが失われるため、これは機能しません。

他のみんなはこれをどのように扱っていますか？

4

1 に答える 1

4

そんなことはできません。というか、やってはいけない。

これを解決するにはいくつかの方法があり、通常は静的ゲートウェイを使用してセッションを取得しますが、問題は、このアプローチでは遅延ロードされたコレクションが作成され、すべての問題が発生することです。

RavenDB は、この種の問題を回避するように特別に設計されています。また、サーバーに戻るのを避けるためにアイテムを含めることもできますが、そのように透過的に ID とタイプの間を移動しようとするべきではありません。

于 2011-08-21T07:46:21.610 に答える