数据库无关的DAO (NoSQL + SQL)

Question

背景

在编写新组件时，我正在为我的存储层做出SQL/NOSQL数据库(Mongo对Mysql)的决策。到今天为止，mysql似乎非常适合我的用例(6-7个域实体，彼此密切相关)。不过，我仍然希望保持数据层抽象的集成，以便将来切换到nosql (mongo)。

在尝试构建这个抽象的数据访问层时，我觉得我正在牺牲RDBMS的大量功能(因为NOSQL不支持作为第一类构造的联接，因此不能将联接和其他著名的RDBMS特性作为这种抽象的一部分公开)。

问题:

首先构建这样的抽象级别是过分的吗？甚至可以在不牺牲RDBMS产品的情况下构建这样的抽象级别吗？如果可能的话，推荐的模式是什么？

Answer 1

确保您与数据库保持合理解耦的最佳方法是不为数据库创建抽象层，但同时仍然可以自由地使用数据库的任何特性。(嗯，除非现在有明确的要求，否则您需要支持多个数据库。否则，YAGNI.)

一个人所能做的最糟糕的事情就是尽量保持“数据库不可知论”。这几乎会自动产生一些“公共分母”类型的接口，通常是琐碎的CRUD操作。然后，您要么不能使用存储后端的任何特定特性(考虑到dbs现在有什么了不起的特性，甚至更不用说完全不同的范例)，要么您必须不断地为特定特性或查询引入新的方法。更糟糕的是，因为你不希望这种抽象“爆炸”，你就会被迫重复使用新的需求方法，这将是不合适的和痛苦的。

另一种方法是对域进行建模，并在有意义的地方提供特定于数据库的实现。我遇到的一个例子是:我们要求冻结客户的所有信用卡(银行域名)。这最初是用ORM实现的，ORM有多个连接实体(数据对象具有通常的1-1/1-n关系)。我们必须对帐户进行查询，然后对卡片进行查询，在卡片上设置标志，然后让ORM处理持久化问题。

相反，我引入了一个方法Customer.freezeCreditCards()，它直接在数据库中触发一个"update“语句。虽然这不是一个特别令人兴奋的操作，但它表明，如果您在某个有意义的业务方法(其数据所在的地方)，那么使用所需的任何优化或额外特性都是非常简单的。而且您也不必抽象/概括特性。

Answer 2

您为什么要创建这样一种抽象程度？

不同的存储技术之所以存在，是因为每种存储技术都有一系列无法概括的优点和缺点--即使是业界的精英和大型公司的经济资源也无法做到这一点。

如果任何存储技术对特定的应用程序来说都是足够的，那么只需选择一个并与其一起运行。

如果您同时为许多存储技术设计和编写代码，同时考虑到所有存储技术的局限性和无存储技术的特殊好处，那么这个过程的结论可能是一个应用程序，速度慢，几乎没有有效的功能。

或者至少，它将是一个应用程序，在这个应用程序中，设计阶段缓慢--速度慢，实现时间长，而且比所需的复杂，验证工作不那么容易完成，进一步的维护和修改将成为一个可怕的挑战。

为一种完整的存储方法设计和编写代码可能是完全足够的.如果以后需要更改存储方法，则可以编写不同的应用程序(以补充或替换原始应用程序)。

Answer 3

确保代码具有灵活性的最佳方法是灵活处理代码。

许多人在使用DB编写代码时犯的错误是，他们钻研DB的手册，学习它提供的每一个疯狂的小特性，并使用它们。很快你就得用那个分贝了。

这正是我们在CPU上遇到的问题。每个CPU都有一组op代码。有些是基本的和受欢迎的。其中一些是活泼的，与众不同的。不稳定和不同的代码会给您带来麻烦，因为现在您的代码只适用于那个CPU。

这是Java拥有JVM的原因之一。它只提供基本和流行的op代码，并指出如何在许多不同的CPU上为您做。更重要的是，它不让你随意地使用那些花哨的和不同的。

如果您想成为DB不可知论者，您可以对数据库做同样的事情。让应用程序需要驱动DB抽象的设计，而不是数据库功能。由于确保代码是灵活的最好的方法是对其进行灵活处理，我建议您在宣布它为不可知论之前，尝试让它与至少两个数据库一起工作，从而测试您的抽象。

您可以为每个数据库提供单独的适配器，但是对于您正在使用的DB应该停止了解。这两个适配器都必须在隐藏所拥有的DB的DB抽象下工作。

这听起来可能是很多工作，但是这样做了，您就不必承担DB可能做的每一件事了。你只需要接受你的应用程序真正需要的东西。您甚至可能会发现，没有DB，您就可以过得去。