当前位置：文江博客话题详情

将存储库模式与文档数据库一起使用是否有意义？

发布于 2024-12-05 20:06:25 字数 281 浏览 0 评论 0原文

我目前正在尝试 MongoDB。我正在从 NHibernate/SQL 思维方式转变，因此最初我实现了用于数据访问的存储库模式。

在我开始使用嵌套文档之前，这一切看起来都很好。现在开始看起来有点不匹配。然而，我对存储库很满意，并且喜欢它们提供的抽象、关注点分离和可测试性。

人们是否成功地将存储库模式与文档数据库结合使用？如果没有，您使用什么数据访问方法？抽象/SoC 怎么样？

原文

分享到QQ

分享到微博

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

发布评论

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

被你宠の有点坏 2024-12-12 20:06:26

这是一个有趣的问题。在使用 MongoDB 时，我选择不使用存储库。这是主要的，因为文档数据库被用作读取存储（因此简化了存储在那里的数据）。

我想您必须重新考虑存储库是什么以及您从额外的抽象层中获得的优势。一个好的设计将尽可能具有最少的层数。

因此，存储库为您提供了一些持久性无知以及在公共数据上下文上使用工作单元的能力。它还可以提高您独立测试数据查询的能力（因为这些查询通常被抽象为可查询或规范）。

此外，一些文档数据库已经提供了存储库模式（RavenDB 等），因此不需要再有另一层。

因此，在我看来，使用存储库并不在于您的数据是否存储为关系表还是文档，而更多在于您从抽象中获得什么。

回复收藏 0 原文

为人所爱 2024-12-12 20:06:26

我不知道这是否对您有帮助，但我正在听播客不久前与 Ayende Rahien 谈论 RavenDB。他建议文档实际上可以很好地映射到 DDD 哲学中的聚合。如果您使用嵌套文档来表示聚合并遇到设计问题，也许嵌套不是最好的方法？

回复收藏 0 原文

我为君王 2024-12-12 20:06:26

思考“我是否应该使用 X”并不像专注于“我应该使用什么”那么有效？

存储库模式的替代方案是什么，权衡是什么，它们与您的领域和实现有何关系？

存储库非常适合在通用存储（例如 SQL）上强制执行一组预定义的模式。对于文档存储，我的印象是文档模式将比您通常在基于 SQL 的存储中看到的更大程度地确定访问模式。在这种情况下实现存储库可能会导致非常泄漏的抽象，其中底层文档结构的更改会对相关业务代码产生 1:1 的影响。在这种情况下，存储库提供的价值非常小。对我来说，文档存储很自然地适合工作单元 (UoW) 范例，其中工作单元是文档（或 doc+嵌套子文档，或文档集）。

正如您所提到的，存储库模式的另一个优点是对存储机制的抽象。代价通常是无法访问 Mongo 的低级实现特定功能。这对你来说值得权衡吗？ NHibernate 与 SQL 紧密耦合，因此对 RDBMS 的所有重要功能具有丰富的功能抽象。我不知道 Mongo 有任何类似的框架，所以你确实会大大提高抽象级别。

您需要支持多个并发数据存储吗？例如，您是否会通过相同的数据层抽象将某些类型的数据写入 SQL，将其他类型的数据写入 Mongo？如果是这样，那么存储库是一个不错的选择。

如果您可以提供有关您的领域和实施的更多详细信息，那么我们可以深入了解您可能需要考虑的具体权衡

回复收藏 0 原文

又怨 2024-12-12 20:06:26

我在生产代码中使用 MongoDB 和存储库模式已有两年多了，我可以说随着时间的推移，它确实对我有帮助。这些抽象非常适合测试（内存中）和生产（MongoDB）。

我使用 Java，代码看起来像这样（大致）：

public interface MyStorage {

    boolean add(MyDoc doc);

    boolean update(MyDoc doc);

    boolean remove(String docId);

    boolean commit();

    MyDoc get(String docId);

    MyStorageQuery newQuery();

    List<MyDoc> query(MyStorageQuery q);

}

我为每个存储实现都有一个工厂，它创建 MyDoc 对象的新实例。
我在 MongoDb 和我自己的手动模拟之间交换实现以进行测试。

MongoDB 实现使用 MyDoc 类，该类扩展了 BasicDBObject，如下所示：

public interface MyDoc {
  Data getData(); // let's assume this is a nested doc
  void setData(Data d);
  String getId();
  long getTimestamp();
  void setTimestamp(long time);
}

MongoDbMyDoc extends BasicDBObject implements MyDoc {
  MongoDbObject() { }
  void setId(String id) {
    this.put("_id", id);
  }
  String getId() {
    return super.get("_id");
  }
  void setData(Data d) {
    dataObj = new BasicDBObject();
    dataObj.put("someField",d.someField);
    dataObj.put("someField2", d.someField2);
    super.put("data",dataObj);
  }
  ...
}

然后，我在实际存储实现中使用 MongoDB Java 客户端从数据库返回我的实现的实例。这是我的 MongoDB 存储实现的构造函数：

public MongoDbMyStorage(DB db, String collection) {
  //DB in a mongodb object (from the client library) which was instantiated elsewhere
  dbCollection = db.getCollection(collection);
  dbCollection.setObjectClass(MongoDbMyDoc.class);
  this.factory = new MongoDbMyDocFactory();
}

这里还有 2 个接口：
MyStorageQuery 它也被实现为 MongoDB 实现的 BasicDBObject，并使用存储接口的 newQuery() 生成。
还有 MyDocFactory ，这里没有介绍，但它基本上是一个文档工厂，知道存储实现是什么并相应地生成 MyDoc 实例。

注意事项：
抽象没有多大意义的一件事是定义 MongoDB 存储使用的索引。我将所有 ensureIndex(...) 调用放在构造函数中，不是很通用，但为每个集合定义索引是 MongoDB 特定的优化，因此我可以接受它。
另一个是提交是使用 getLastError() 命令实现的，根据我的经验，该命令效果不佳。这对我来说不是问题，因为我几乎从未明确提交更改。

I use MongoDB in production code with the Repository Pattern for over 2 years now and I can say that it really helped me over time. The abstractions serve well for testing (in-memory) and production (MongoDB).

I use Java and the code looks something like this (roughly):

public interface MyStorage {

    boolean add(MyDoc doc);

    boolean update(MyDoc doc);

    boolean remove(String docId);

    boolean commit();

    MyDoc get(String docId);

    MyStorageQuery newQuery();

    List<MyDoc> query(MyStorageQuery q);

}

I have a factory for each storage implementation which creates new instances of the MyDoc object.
I interchange the implementation between MongoDb and my own hand-rolled mock for testing.

The MongoDB implementation uses a MyDoc class which extends the BasicDBObject like so:

public interface MyDoc {
  Data getData(); // let's assume this is a nested doc
  void setData(Data d);
  String getId();
  long getTimestamp();
  void setTimestamp(long time);
}

MongoDbMyDoc extends BasicDBObject implements MyDoc {
  MongoDbObject() { }
  void setId(String id) {
    this.put("_id", id);
  }
  String getId() {
    return super.get("_id");
  }
  void setData(Data d) {
    dataObj = new BasicDBObject();
    dataObj.put("someField",d.someField);
    dataObj.put("someField2", d.someField2);
    super.put("data",dataObj);
  }
  ...
}

I then in the actual storage implementation use the MongoDB Java client to return instances of my implementation from the DB. Here is the constructor for my MongoDB storage implementation:

public MongoDbMyStorage(DB db, String collection) {
  //DB in a mongodb object (from the client library) which was instantiated elsewhere
  dbCollection = db.getCollection(collection);
  dbCollection.setObjectClass(MongoDbMyDoc.class);
  this.factory = new MongoDbMyDocFactory();
}

There are 2 more interfaces here:
MyStorageQuery which is also implemented as a BasicDBObject for the MongoDB implementation and generated using the newQuery() of the storage interface.
And MyDocFactory which isn't presented here, but it is basically a document factory that knows what the storage implementation is and generates the MyDoc instances accordingly.

Caveats:
One thing where the abstraction doesn't make much sense is in defining the indexes used by the MongoDB storage. I put all my ensureIndex(...) calls in the constructor, not very generic, but defining indexes per collection is a MongoDB specific optimization so I can live with it.
Another is that commit is implemented using the getLastError() command which from my experience didn't work so well. It isn't a problem for me since I almost never explicitly commit a change.

回复收藏 0 原文