数据映射器设计模式和网关

Question

如果我错了，请纠正我：

如果我们使用 Dao/Vo 模式或 TDG 模式，我们将通过为每个（或至少很多）表提供一个相关的类来拥有一个很好的代码组织。

这种方法的问题是数据未在给定表内关闭。我们有一些特定于域的数据，例如

findDogBreed();

或

findBookBestSellerAuthor();

，上面的模式似乎不能很好地处理这个问题。

解决方案是使用Mappers。映射器将包含一组与一个表相关的方法和属性，但它们不会仅与该表关闭，也不会与特定的 SQL 模式相关。

问题是，如果我们开始抽象所有这些东西，我们将无法访问 SQL 语法。如果我们需要数据库管理员来处理它怎么办？对于更复杂的查询，使用映射器可能会导致非常混乱的抽象“事物”。

这是正确的吗？如果是这样，我想知道我们有什么途径可以在这里找到一个中间项。

Answer 1

在抽象功能时，即使在多个抽象级别上，您也不必失去手动编写 SQL 的选项。

例如看一下 Doctrine，它是受 Hibernate 启发的 PHP ORM。它允许您用 DQL（Doctrine Query Language）编写查询，将其转换为 SQL 并自动映射您的实体，但您也可以编写native SQL（最常用于性能优化），但您需要自己定义结果映射.