我正在尝试设计一种将依赖注入与 ORM 工具一起使用的方法,以便在需要时可以轻松替换它们。问题是似乎不可能将 orm 代码与程序分开。即使我能够分离保存、获取等功能,我也无法替换浮动的实体实例。
我想知道我正在努力实现的目标是否合理。如果是这样,有什么好的方法可以实现这一目标?
我正在尝试设计一种将依赖注入与 ORM 工具一起使用的方法,以便在需要时可以轻松替换它们。问题是似乎不可能将 orm 代码与程序分开。即使我能够分离保存、获取等功能,我也无法替换浮动的实体实例。
我想知道我正在努力实现的目标是否合理。如果是这样,有什么好的方法可以实现这一目标?
无论您做什么,都将依赖于应用程序的某个级别/层。我的意思是,一旦你引入了 3rd 方代码,它就需要在某个地方连接到你的应用程序。
您可以使用存储库模式并在您的解决方案中创建一个存储库项目,并将所有与 LLBLGen 相关的代码保留在其中。您将通过它进行所有数据库交互,并且必须将一些 DTO 样式的对象传入和传出它以避免泄漏。您还必须在存储库中完成 LLBLGen 和 DTO 之间的所有映射。
所以,如果我们谈论的是一个 webapp,你可以有类似 WebAPI <-> 业务层 <-> 存储库层 <-> ORM 的东西
此外,实际上您不太可能决定将 ORM 换成不同的 ORM(尤其是 LLBLGen,因为它是一个非常好的 ORM),所以您可能稍微多虑了这一点。你应该明智地选择一个 ORM 并坚持下去。如果您已经知道以后想换掉它,为什么不马上换掉呢?而且您通常不会将 DI 与 LLBLGen 实体对象之类的东西一起使用(并不是说您不能)。这有点像说您想为 DateTime 使用 DI,以防您决定改用 Noda Time 来处理日期。DI 的主要目的是使您的代码可测试,即使在业务层中有 LLBLGen 实体,这也不是问题,您仍然可以模拟 repo 方法并很好地测试业务层。
一些说明:
DTO = 数据传输对象
DI = 依赖注入