数据映射器设计模式和网关
如果我错了,请纠正我:
如果我们使用 Dao/Vo 模式或 TDG 模式,我们将通过为每个(或至少为很多)表提供一个相关的类来拥有一个很好的代码组织。
这种方法的问题是数据未在给定表内关闭。我们有一些特定于域的数据,例如 findDogBreed();
或 findBookBestSellerAuthor();
并且上述模式似乎无法处理此问题很好。
一个解决方案是使用映射器。映射器将包含一组与一个表相关的方法和属性,但它们不会仅与该表关闭,也不会与特定的 SQL 模式相关。
问题是,如果我们开始抽象所有这些东西,我们将无法访问 SQL 语法。如果我们需要数据库管理员来处理它怎么办?对于更复杂的查询,使用映射器可能会导致非常混乱的抽象“事物”。
这是正确的吗?如果是这样,我想知道我们有什么途径可以在这里找到一个中间项。
Please, correct me if I'm wrong:
If we use a Dao/Vo pattern or a TDG pattern we will have a nice code organization by having for each (or at least for a lot of) tables a related class.
The problem with this approach is that or data IS NOT closed inside a given table. We have some domain specific data, like findDogBreed();
or findBookBestSellerAuthor();
and the above patterns don't seem to deal with this nicely.
Once solution is to use Mappers. Mappers will contain a set of methods and properties related to one table BUT they will not be closed to that table only nor will they be related to a specific SQL Schema.
The problem is, if we start to abstract all those things, we will NOT have access to SQL syntax. What if we need our database administrator to work on it ? And on more complex queries, using mappers could lead to a really messy abstraction "thing".
Is this correct ? If so, I'm wondering what paths do we have in order to find a middle term here.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当您抽象功能时,即使在多个抽象级别上,您也不必失去手动编写 SQL 的选项。
例如,看看 Doctrine,它是受 Hibernate 启发的 PHP ORM。它允许您用 DQL(Doctrine 查询语言)编写查询,该查询会转换为 SQL 并自动映射您的实体,但您也可以编写 原生 SQL(最常用于性能优化),但需要自己定义结果映射。
You don't have to lose the option to write SQL manually when you abstract the functionality, even on multiple levels abstraction.
E.g. look at Doctrine, which is Hibernate-inspired ORM for PHP. It allows you to write queries in DQL (Doctrine Query Language) that translates to SQL and automatically maps your entities, but you can also write native SQL (most often for performance optimization), but you need to define the result mapping by yourself.