thirst and thrust

In reading about PHP data access one thing that I notice is a lot of example that explain reading and writing to a database have the mysql_connect() function and write/execute SQL statement directly in the page code. Coming from an enterprise architecture background this makes me cringe. It really reminds me of my early days of hacking VBScript in ASP or inheriting J2EE solutions where logic is embedded into the JSP pages. From those days I know that code embedded in the page is hard to maintain. When the application gets complex it can get down right impossible to make changes or track down bugs.

There is a value in separating presentation code from business logic and business logic from the data access logic. I am only going to talk about database access in this post. This is in line with my previous post OO Design Principal: Separate Changing Functionality. Database logic will be one of the highest risk areas for chance in most applications.

What is the value of separating database connection and data read/write logic from the presentation (page) code?

• It reduces the coupling between your object schema and your data schema, increasing your ability to evolve either one.
• It implements all data-related code in one place.
• It simplifies the job of application programmers and code maintainers.
• It allows application programmers to focus on the business problem in one area while focusing on data access on the database in another.
• It gives you a common place to implement data-oriented business rules.
• It can takes advantage of specific database features, increasing application performance.
• Makes changing database schema’s or even database vendors much easier to implement

There are a number of strategies for separating database access in your code.

• One approach is to put data access code in your business (or domain) objects [classes that implement the actors or domain information in your program]. The idea here is to make your objects smarter and know how to access and populate members in the class within itself. This moves the database code out of the presentation code, which is good, but couples database access logic with your business logic.
• Data access objects (DAOs) encapsulate the database access logic required of business objects. The typical approach is for there to be one data access object for each business object, for example the Person class would have a Person_Data class. The Person_Data class implements the SQL code required to access the database, similar to the previous approach. The main advantage of data access objects over the previous approach is that your business classes are no longer directly coupled to the database access logic.
• A persistence framework fully encapsulates database access from your business objects. Instead of writing code to implement the logic required to access the database you instead define meta data that represents the mappings. So, if the Person class maps to the T_Person table part of the meta data would represent this mapping. Meta data representing the mappings of all business objects, as well as the associations between them would also need to exist. Based on this meta data the persistence framework would generate the database access code it requires to persist the business objects.

The list by no means exhaust all the data access approaches but represents the most common ones.

An open question in my mind is what approach best fits with PHP? It seems the selling point of PHP is that it is easy to implement and the start up of learning it is much simpler than other languages/technologies. By adding the concept of a data access layer does that muddy the waters causing PHP to lose it’s edge? Are there any PHP specific or recommended persistence frameworks out there?

Share on Facebook