c#MongoDB(noRM) - 包含嵌入文档的存储库模式

时间:2010-12-29 14:03:39

标签: c# mongodb norm

我正在开发一个类似于Stack Overflow的模型的应用程序(问题/答案等......) Modelling a NoSQL Forum Application with C# / ASP.net MVC

该模型看起来像这样(简化)

class Question
{
    public string Title { get; set; }
    public string Body { get; set; }
    public DateTime DateCreated { get; set; }

    public string UserName { get; set; }

    public List<Answer> Replies { get; set; }
}

class Answer
{
    public string Body { get; set; }
    public DateTime DateCreated { get; set; }

    public string UserName { get; set; }
}

所以我的文档只是一个文档,其中嵌入了“答案”

我正在尝试为这种方法设计我的存储库。

我应该有2个单独的存储库吗?例如:

interface IQuestionRepository
{
    void PutQuestion(Question question);
    Question GetQuestion(string questionID);
}  

interface IAnswerRepository
{
    void PutAnswer(string questionID, Answer Answer);
    Answer GetAnswer(string answerID);
}

或类似的东西:

interface IPostRepository
{
    void PutQuestion(Question question);
    Question GetQuestion(string questionID);
    void PutAnswer(string questionID, Answer Answer);
    Answer GetAnswer(string answerID);
}

3 个答案:

答案 0 :(得分:6)

你的模型本质上存在缺陷。

问题应该是根文件。

答案应该是根文件。

关于RavenDB的文档,文档建模信息大多可以直接用于您:http://codeofrob.com/archive/2010/12/21/ravendb-document-design-with-collections.aspx

编辑:FWIW您的模型存在缺陷的原因是文档数据库您希望文档为事务边界建模。考虑堆栈溢出的编辑场景以及与多个人添加和更新所有更改根文档的答案保持一致性的噩梦是多少,并且海报正在更新问题。单个对象上的争用量很大。

RavenDB提供他们称之为“修补”的东西,它允许你操作文档结构的一部分而不是整个文档来解决这样的问题但是这个设计最好在前面避免,而不是试图通过大大增加持久性模型的复杂性必须进行部分更新并处理精细的并发情况。

在此之后回答具体问题,那么你将有一个AnswersRepository和一个QuestsionsRepository

答案 1 :(得分:0)

我认为最好为每个聚合rute创建存储库(仅用于问题文档)

答案 2 :(得分:-1)

您不需要答案的存储库。从域的角度来看,您应该只添加Question对象的答案。问题存储库应该完成工作,因为问题看起来像聚合根,并且每个聚合根(而不是每个实体)应该有一个存储库。

您应该注意不要创建Anemic Domain Model