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

Question

我正在开发一个应用程序，其模型类似于 Stack Overflow（问题/答案等......） 使用 C# / ASP.net MVC 建模 NoSQL 论坛应用程序

该模型看起来像这样（简化）

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);
}

Answer 1

你的模型本质上是有缺陷的。

问题应该是根文件。

答案应该是根文件。

虽然是针对 RavenDB 编写的，但文档建模信息大多可以直接供您使用：http://codeofrob.com/archive/2010/12/21/ravendb-document-design-with-collections.aspx

编辑： FWIW原因您的模型的缺陷在于，对于文档数据库，您希望文档对事务边界进行建模。想想堆栈溢出的编辑场景，以及与多人添加和更新答案（所有这些都改变了根文档）保持一致性将是多么一场噩梦，而发布者正在更新问题。单个对象上的争用量将非常成问题。

RavenDB 提供了他们所谓的“修补”功能，可以让您操作文档结构的一部分而不是整个文档来解决此类问题，但最好预先避免这种设计，而不是试图通过大大增加文档的复杂性来使其工作。持久化模型必须进行部分更新并处理复杂的并发情况。

要回答此后的具体问题，您将拥有一个 AnswersRepository 和一个 QuestionsRepository

Answer 2

我认为最好为每个聚合路由创建存储库（仅适用于问题文档）

Answer 3

您不需要答案的存储库。从领域的角度来看，您应该将答案添加到问题对象中。问题存储库应该完成这项工作，因为问题看起来像一个聚合根，并且您应该为每个聚合根（而不是每个实体）拥有一个存储库。

您应该小心，不要创建贫血域模型。