PHP MVC:“数据映射器"层的查询构建器类 [英] PHP MVC: Query builder class for Data Mapper layer
问题描述
我正在使用PHP开发自己的MVC框架.其模型层由
I'm working on my own MVC framework in PHP. Its model layer consists of
- Domain objects (also known as "models"), which encapsulate the business logic and
- Data mappers, for transfering the data between the domain objects and the database.
不存在数据映射器抽象类，每个数据映射器类都包含其自己的数据访问层实现.数据映射器的类方法包含或将包含复杂的sql语句.
A data mapper abstract class does not exist, each data mapper class containing its own implementation of the data access layer. The class methods of the data mappers contain, or will contain complex sql statements.
我的问题:在这种情况下，是使用查询生成器类-负责构建sql语句-是一个限制，还是有一些很好的参数，为什么应实施此组件?
My question is: Under these circumstances, is the use of a query builder class - responsible for building the sql statements - a limitation, or are there some good arguments, why this component should be implemented?
感谢您的帮助.谢谢.
推荐答案
1.)功能强大的查询生成器可能是一个优点，因为它可以提供抽象SQL方言的接口.因此，您可以编写数据映射器实现，而无需考虑将要使用的特定RDBMS.
1.) A well featured query builder could be an advantage, in that it could provide an interface which would abstract the SQL dialect. Therefore, you could write your data mapper implementations without the need to consider the specific RDBMS you will be working with.
2.)在我的某些DAO或Service类中，我可能有两个(或更多)函数，它们对同一张表执行稍有不同的查询.有时，这些查询可能非常大，并且具有许多联接或子查询，而仅在WHERE子句中使用的列有所不同.将这些功能与getEmployeesAgedBetween(Range<Integer> range)和getSalariedEmployeesAgedBetween(Range<Integer> range)之类的签名分隔开可能是有意义的，但根据您的需要，这些功能的数量可以迅速增加.希望重构这样的情况，我的目标是找到一种更健壮的方法，该方法将这些方法之间的所有可能差异参数化.显然，我只是想在幕后制作一个更动态的WHERE子句，因此我不一定需要一个成熟的查询生成器.但是，WHERE子句生成器将非常有用.使用这样的实现，我可以将上述函数重构为带有签名的单个方法，例如getEmployees(Where<EmployeeDAO.FIELDS> where).实际上，我已经实现了这种方法，在以前的实现中，我和我的同事都喜欢使用并维护这种方法.
2.) In some of my DAO or Service classes, I may have two (or more) functions that perform slightly different queries against the same table(s). Sometimes, these queries can be quite large, and have a number of joins or sub-queries while only differing in the columns used in the WHERE clause. While it might make sense to keep these functions separated with signatures like, getEmployeesAgedBetween(Range<Integer> range) and getSalariedEmployeesAgedBetween(Range<Integer> range), these functions can grow quite quickly in number based upon your needs. Looking to refactor a case like this, I would aim for a more robust method that parameterizes all possible differences between these methods. It is apparent that I am only looking to make a more dynamic WHERE clause under the hood, so I would not necessarily need a full-fledged query builder. However, a WHERE clause builder would be quite useful. Using such an implementation, I could refactor the above functions into a single method with a signature like getEmployees(Where<EmployeeDAO.FIELDS> where). I have actually implemented such a method, and both my coworkers and myself have enjoyed working with, and maintaining such methods over the prior implementations.
这篇关于PHP MVC:“数据映射器"层的查询构建器类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
