MongoDB C# 驱动程序 - POCO 引用的序列化?
我目前正在研究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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
C# 驱动程序可以处理包含对其自身另一个实例的引用的类的序列化 (1)。但是:
如果您想将其存储为单独的文档,则必须使用第二个类(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:
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/
是的,这是完全可能的。
关于 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.
如果您确实想要引用另一个文档,可以使用 DBRef。然而,MongoDB 中的引用存在限制。
If you really want a reference to another document, you can use a DBRef. However there is limitation with references in MongoDB.
我最近遇到了同样的问题,我通常会避开它们,但是......我认为这对于部署在 Id 字段上的重要编号系统来说可能是一个很好的用途。
因此,简化一下,如果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.
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?