MongoDB C# 驱动程序 - POCO 引用的序列化?

发布于 2024-11-18 00:53:34 字数 839 浏览 2 评论 0原文

我目前正在研究MongoDB。据我了解,官方 C# 驱动程序可以执行 POCO 的序列化和反序列化。我还没有找到有关如何序列化两个对象之间的引用的信息。 [我正在谈论的内容将被表示为两个单独的文档,带有 ID 链接,而不是嵌入文档。

序列化机制能处理这种情况吗? (1):

class Thing {
    Guid Id {get; set;}
    string Name {get; set;}
    Thing RelatedThing {get; set;}
}

或者我们是否必须牺牲一些面向对象编程,并做这样的事情? (2) :

class Thing {
    Guid Id {get; set;}
    string Name {get; set;}
    Guid RelatedThing_ID {get; set;}
}

更新:

只是几个相关的问题...

a) 如果序列化器能够处理情况 (1)。如何在不使用嵌入的情况下执行此操作的示例是什么?

b) 如果使用嵌入,是否可以查询所有“事物”,无论它们是“父元素”还是嵌入元素?这样的查询会是什么样子?

I'm researching MongoDB at the moment. It's my understanding that the official C# driver can perform serialization and deserialization of POCOs. What I haven't found information on yet is how a reference between two objects is serialized. [I'm talking about something that would be represented as two seperate documents, with ID links, rather than embeded documents.

Can the serialization mechanism handle this kind of situation? (1):

class Thing {
    Guid Id {get; set;}
    string Name {get; set;}
    Thing RelatedThing {get; set;}
}

Or do we have to sacrifice some OOP, and do something like this? (2) :

class Thing {
    Guid Id {get; set;}
    string Name {get; set;}
    Guid RelatedThing_ID {get; set;}
}

UPDATE:

Just a couple of related questions then...

a) If the serializer is able to handle situation (1). What is an example of how to do this without using embedding?

b) If using embedding, would it be possible to query across all 'Things' regardless of whether they were 'parents' or embedded elements? How would such a query look like?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

泪意 2024-11-25 00:53:34

C# 驱动程序可以处理包含对其自身另一个实例的引用的类的序列化 (1)。但是:

  1. 正如您所猜测的,它将使用嵌入来表示
  2. 对象图中不能有循环路径,否则会发生堆栈溢出

如果您想将其存储为单独的文档,则必须使用第二个类(2)和进行多次插入。

当对象存储为具有嵌套嵌入的大型文档时,跨多个级别的查询实际上是不可能的。您可能想看看一些替代方案,例如:

https://docs .mongodb.com/manual/applications/data-models-tree-structs/

The C# driver can handle serializing the class containing a reference to another instance of itself (1). However:

  1. As you surmised, it will use embedding to represent this
  2. There must be no circular paths in the object graph or a stack overflow will occur

If you want to store it as separate documents you will have to use your second class (2) and do multiple inserts.

Querying across multiple levels is not really possible when the object is stored as one large document with nested embedding. You might want to look at some alternatives like:

https://docs.mongodb.com/manual/applications/data-models-tree-structures/

聆听风音 2024-11-25 00:53:34

是的,这是完全可能的。

关于 MongoDB 和大多数 NoSQL 解决方案,您必须了解的一件事是对象可以包含在其他对象中。对于 MongoDB 来说,基本上,如果您可以在 JSON 中创建对象,那么您就可以在 MongoDB 中创建该对象。

一般来说,您应该努力拥有“相对”非规范化的数据库结构。只要不经常更新,一点点重复的数据就可以了。

Yes, That is completely possible.

One thing you must understand about MongoDB and most NoSQL solutions is that objects can be contained within other objects. In the case of MongoDB, it's basically, if you can create the object in JSON, then you can create the object in MongoDB.

In general, you should strive to have a "relatively" denormalized database structure. A little bit of duplicated data is ok as long as you're not updating it often.

寻找一个思念的角度 2024-11-25 00:53:34

如果您确实想要引用另一个文档,可以使用 DBRef。然而,MongoDB 中的引用存在限制。

  • 当您获取 Thing 的文档时,您只能通过 ref 上的 id 进行查询
  • ,您必须进行第二次查询才能获取关联的 RelatedThing 文档,因为 MongoDB 中不存在 join。

If you really want a reference to another document, you can use a DBRef. However there is limitation with references in MongoDB.

  • you can only query by id on a ref
  • when you get your Thing's document, you'll have to make a second query to get the associated RelatingThing's document as join doesn't exists in MongoDB.
醉生梦死 2024-11-25 00:53:34

我最近遇到了同样的问题,我通常会避开它们,但是......我认为这对于部署在 Id 字段上的重要编号系统来说可能是一个很好的用途。

class Thing {
string Id {get; set;}
string Name {get; set;}
string RelatedThing {get; set;}}

因此,简化一下,如果Id类似于“T00001”(或者实际上是T + GUID),您可以轻松地获取事物集 Mongo 通过查询类似 Id 以 T 开头的内容,并为它们全部设置对象(或者仅为您知道包含引用的子集,如果它是一个非常大的集合)。

您知道/期望 RelatedThing 是一个 Thing,但当它从 Mongo 返回时它只是一个字符串。但是,如果您已经按照上面的方式设置了对象,则可以有效地使用该字符串,就好像它是一个对象引用一样(毕竟,这就是它的真正含义,是“手动”完成的)。

这是一种“宽松”的做法,但可能对您有用。

任何人都可以看到这种方法有任何陷阱吗?

I've encountered the same issue recently, and I usually steer away from them but... I'm thinking that this could be a good use for a significant numbering system deployed on the Id field.

class Thing {
string Id {get; set;}
string Name {get; set;}
string RelatedThing {get; set;}}

So, simplifying, if Id was something like "T00001" (or indeed T + GUID), you could easily get the set of things from Mongo by querying for something like Id starts with T, and setting up objects for them all (or just for the subset you know contains your reference, if it is a very large set).

You know/expect that RelatedThing to be a Thing, but it will just be a string when it comes back from Mongo. But if you've set up objects as above, you could effectively use the string as if it were an object reference (after all, that is what it really is, done kind of "manually").

Its a 'loose' way of doing it, but might be workable for you.

Can anyone see any pitfalls with that approach?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文