Models in the Zend Framework – Part 1

Preamble: This series of articles deals with providing a generic model class for use in the Zend Framework.

The Zend Framework is my PHP framework of choice. It has great code quality, an active and supportive community and is backed by the PHP company, Zend. Its Model-View-Controller structure however, is not complete by any means. I really like the controllers, the View gets a B- (because of the dreadful viewRenderer) but the models are practically non-existent.

This is actually by design, as the framework’s developers decided not to provide a default model class. There was much debate at the early stages of the framework’s inception whether to adopt various ORM patterns into the framework for such usage. It was decided to leave it at a lower abstraction level, leaving us with mainly the Zend_Db_Table class to build on.

Personally I agree with this decision on a certain level – I am not an avid fan of any of the currently available ORM implementations (though I’m always hoping that a perfect one will come along). I do believe though that a basic Model class should have been provided to provide solutions to very basic web needs.

So what is missing:

1. Filtering and validation.

Filtering and validating user input is a basic requirement for a web application. You want to ensure data used in SQL queries is safe (SQL injections much?) and also to provide users with feedback if they have entered the wrong information in forms (ie, user feedback).

The Zend Framework actually provides several components to handle filtering and validation – Zend_Filter, Zend_Validate and Zend_Filter_Input, all of which I will be employing in the proposed solution throughout this series.

2. Handling table relationships where it matters

Proper database modeling requires that tables should be normalized. In most real world cases, normalization would result in related data split over several tables (to model 1-to-many and many-to-many relationships). Retrieving such information in an efficient manner requires the use of JOIN statements (we’re talking about SQL databases here).

This is where most ORM solutions fail in my opinion (including Zend_Db_Table, which is not a complete ORM). They provide a method to iterate over result-sets and retrieve related sets – resulting in as many queries as there are rows in the original set. Some provide an alternative to manually perform JOIN operations, but ideally JOIN conditions would be automatically selected based on the table relationships.

I have submitted a proposal to the Zend Framework for a component that provides just that (using the Zend_Db_Table reference map which defines relationships between tables). So far there hasn’t been much (any) response to it. I will provide it here with explanations in the hopes that it will prove useful to someone other than me.

Coming up

In the next part I will go over implementing validation and filtering methods which are tied to the model and the resulting table schema. I will also suggest how to integrate those features into the controllers and the views.

To know when the next article is published, please subscribe to new articles using your Email below or follow me on Twitter.

Subscribe to Blog via Email

Enter your email address to receive notification about new posts.

  • http://weierophinney.net/matthew/ Matthew Weier O’Phinney

    Note: I’m a Software Architect with Zend Framework.

    Our “party line” regarding the Model in ZF has always been “Model !== Database”. Basically, in this Web 2.0 world we inhabit now, the database is only one potential _backend_ for a Model — web services, the file system, and configuration files are all also potential model storage.

    With that in mind, abstracting the model becomes something quite different from models as encapsulated in other frameworks. We’re looking primarily at filter/validation chains (ala Zend_Filter_Input and/or Zend_Form) and storage backend as the key components, with the possibility of also including generic interfaces for results and resultsets.

    Regarding your proposal, we have recently ratified a new proposal process, and are in the process (excuse the pun) of actively reviewing our backlog of proposals; hopefully you will see movement on yours in the coming month.

    I look forward to reading more of this series!

  • http://weierophinney.net/matthew/ Matthew Weier O’Phinney

    Note: I’m a Software Architect with Zend Framework.

    Our “party line” regarding the Model in ZF has always been “Model !== Database”. Basically, in this Web 2.0 world we inhabit now, the database is only one potential _backend_ for a Model — web services, the file system, and configuration files are all also potential model storage.

    With that in mind, abstracting the model becomes something quite different from models as encapsulated in other frameworks. We’re looking primarily at filter/validation chains (ala Zend_Filter_Input and/or Zend_Form) and storage backend as the key components, with the possibility of also including generic interfaces for results and resultsets.

    Regarding your proposal, we have recently ratified a new proposal process, and are in the process (excuse the pun) of actively reviewing our backlog of proposals; hopefully you will see movement on yours in the coming month.

    I look forward to reading more of this series!

  • http://www.techfounder.net Eran Galperin

    I agree with your general sentiments (as I said in the post). I do believe though, that the Framework should come ready with a class that provides the integration between the db classes, input filtering and several other utility methods, as this is a generic use-case that each model would require.

    It’s great to hear there’s progress on the proposals, it seemed to be stuck in neutral for a while now.

  • http://www.techfounder.net Eran Galperin

    I agree with your general sentiments (as I said in the post). I do believe though, that the Framework should come ready with a class that provides the integration between the db classes, input filtering and several other utility methods, as this is a generic use-case that each model would require.

    It’s great to hear there’s progress on the proposals, it seemed to be stuck in neutral for a while now.

  • Pingback: techfounder » Models In The Zend Framework - Part 2()

  • Paul White

    This looks interesting and would be a useful series for me.

    But, where is part 2!!!

  • Paul White

    This looks interesting and would be a useful series for me.

    But, where is part 2!!!

  • Paul White

    nm foundit :)

  • Paul White

    nm foundit :)