PHP MVC: Query builder class for Data Mapper layer

问题:

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.

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.

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?

I appreciate your help. Thank you.

回答1:

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.) 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.