如何组织数据库访问层?

abl*_*lmf 11 python database testing orm mocking

我正在使用SqlAlchemy,一个python ORM库.我曾经通过调用SqlAlchemy API直接从业务层访问数据库.

但后来我发现这会导致我运行所有测试用例的时间过长,现在我想也许我应该创建一个数据库访问层,所以我可以在测试期间使用模拟对象而不是直接访问数据库.

我认为有两种选择:

  1. 使用包含数据库连接的单个类和许多方法,如addUser/delUser/updateUser,addBook/delBook/updateBook.但这意味着这个课程会非常庞大​​.

  2. 另一种方法是创建不同的管理器类,如"UserManager","BookManager".但这意味着我必须将管理器列表传递给Business层,这看起来有点麻烦.

您将如何组织数据库层?

rob*_*rob 5

这是个好问题!
问题不是微不足道的,可能需要几种方法来解决它.例如:

  1. 组织代码,以便您可以在不访问数据库的情况下测试大多数应用程序逻辑.这意味着每个类都有访问数据的方法,以及处理数据的方法,第二个类可以很容易地进行测试.
  2. 当您需要测试数据库访问时,您可以使用代理(因此,如解决方案#1); 您可以将其视为SqlAlchemy的引擎或SA的替代品.在这两种情况下,您可能想要自我初始化假.
  3. 如果代码不涉及存储过程,请考虑使用内存数据库,如Lennart所说(即使在这种情况下,称之为"单元测试"可能听起来有点奇怪!).

但是,从我的经验来看,一切都很容易,然后当你去场时突然下降.例如,当大多数逻辑在SQL语句中时该怎么办?如果访问数据与其处理严格交错怎么办?有时您可能能够重构,有时(特别是对于大型和遗留应用程序)不能.

最后,我认为这主要是心态问题.
如果您认为需要进行单元测试,并且需要让它们快速运行,那么您可以以某种方式设计应用程序,以便更轻松地进行单元测试.
不幸的是,这并不总是正确的(许多人认为单元测试可以在一夜之间运行,所以时间不是问题),并且你得到的东西不是真正的单元可测试的.