dsgwii4867
2011-04-25 14:08
浏览 46
已采纳

数据映射器设计模式和网关 - 新手问题

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.

图片转代码服务由CSDN问答提供 功能建议

如果我错了,请纠正我:

如果我们使用 在Dao / Vo模式或TDG模式中,我们将通过为每个(或至少很多)表格提供相关类来获得良好的代码组织。

此方法的问题在于,或者数据未在给定表内关闭。 我们有一些域特定数据,比如 findDogBreed(); findBookBestSellerAuthor(); ,上面的模式似乎没有解决这个问题 很好。

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

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

这是正确的吗? 如果是这样,我想知道我们有什么路径可以在这里找到一个中间词。

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

1条回答 默认 最新

  • douzun4443 2011-05-06 13:34
    已采纳

    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.

    点赞 打赏 评论

相关推荐 更多相似问题