c# - 如何使用 BsonClassMap 将 POCO 域对象属性映射为手册或 DBRef 引用？

Question

使用 BsonClassMap，是否可以映射域对象引用，同时保持域对象程序集持久无知(将 public A Reference { get; set; } 属性更改为 public MongoDBRef Reference { get; set; } 下面的示例类 B 是 Not Acceptable )。

在这种情况下，引用的对象不是同一聚合的一部分，不应存储为嵌套文档。

是否可以像这样在关系中映射两个域对象:

public class A
{
    public Guid Id {get; private set; }
}

public class B
{
    public Guid Id { get; private set; }
    public A Reference { get; set; }
}

进入如下文档结构:

// Collection for class A
{ _id: "11111111-1111-1111-1111-111111111111" }

// Collection class B
{ 
    _id: "22222222-2222-2222-2222-222222222222",
    reference_id: "11111111-1111-1111-1111-111111111111"
}

映射可能如下所示:

BsonClassMap.RegisterClassMap<A>(cm => 
{
    cm.MapIdProperty(c => c.Id)
        .SetIdGenerator(new GuidGenerator())
        .SetRepresentation(BsonType.String);
}

BsonClassMap.RegisterClassMap<B>(cm => 
{
    cm.MapIdProperty(c => c.Id)
        .SetIdGenerator(new GuidGenerator())
        .SetRepresentation(BsonType.String);

    // How do I map the B.Reference to a manual reference (like 
    // the sample doc structure above) or possibly as a DBRef?
}

因此，在不更改模型的情况下，如何将 Reference 属性映射到对象 A，从对象 B 作为 DBRef 或作为手册引用(如我上面的示例文档结构)？

这可能使用 BsonClassMap 吗？或者为了使用 BsonClassMap 并保持我的域程序集持久无知，我是否需要将模型更改为:

public class A
{
    public Guid Id {get; private set; }
}

public class B
{
    public Guid Id { get; private set; }
    public Guid ReferenceId { get; set; } // Don't reference the object directly,
                                          // just store the Guid to the 
                                          // referenced object.
}

Answer 1

我向 mongodb-csharp 用户组提出了同样的问题，并得到了 craiggwilson 的回复:

You'll need to change your ReferenceProperty to ReferencePropertyId. We do not support lazy-loading (or eager-loading) of referenced documents.

Since A is not the aggregate for B, then this actually makes more sense when discussing in these terms. Generally, it is unnecessary for a referenced aggregate (B) to be loaded in order to process the referencing aggregate (A). It might be that you do indeed need some information from B. In this case, think about denormalizing a little and creating a true entity (BSummary) whose aggregate is A. This would make sense if some of the summary information is immutable or changes infrequently.