Here are quick previews to Matthew’s posts on Zend Framework’s Models.
First up is: Using Zend_Form in Your Models
Many other frameworks tie the Model to data access — typically via the ActiveRecord pattern or a Table Data Gateway — which completely ignores the fact that this is tying the Model to the method by which it is persisted. What happens later if you start using memcached? or migrate to an SOA architecture? What if, from the very beginning, your data is coming from a web service? What if you do use a database, but your business logic relies on associations between tables?
While the aforementioned posts do an admirable job of discussing the various issues, they don’t necessarily give any concrete approaches a developer can use when creating their models. As such, this will be the first in a series of posts aiming to provide some concrete patterns and techniques you can use when creating your models. The examples will primarily be drawing from Zend Framework components, but should apply equally well to a variety of other frameworks.
Input Filtering and Forms
In most cases, you want your model to perform its own input filtering. The reason is because input filtering is domain logic: it’s the set of rules that define what input is valid, and how to normalize that input.
However, how does that fit in with forms? Zend Framework has a Zend_Form component, which allows you to specify your validation and filter chains, as well as rules for how to render the form via decorators. The typical pattern is to define a form, and in your controller, pass input to it; if it validates, you then pass the values to the model.
What if you were to instead attach the form to the model?
Some argue that this violates the concept of “separation of concerns”, due to the fact that it mixes rendering logic into the model. I feel this is a pedantic argument. When attached to a form, Zend_Form can be used strictly as an input filter; you would pull the form from the model when you wish to render it, and perform any view-specific actions — configuring decorators, setting the action and method, etc — within your view script. Additionally, the various plugins — validators, filters, decorators — are not loaded until they are used — meaning there is little to no overhead from the decorators when you merely use Zend_Form as an input filter.
Basically, this approach helps you adhere to the DRY principle (one validation/filter chain), while simultaneously helping you keep a solid separation of business and view logic. Finally, you gain one or more form representations of your model, which helps with rapid application development, as well as providing a solid, semantic tie between the model and the view.
So, on to the technique.
Attaching Forms to Models
What I’ve been doing is adding a getForm() accessor to my models that takes an optional argument, the type of form to retrieve. This is then used within the model any time validation is necessary. (Some models require multiple forms, so best to plan for it early. A good example is a model that represents a user — you will need a login and registration form.) Let’s look at it in action:
Click here to see the complete post.
And then Applying ACL to Models.
Zend_Acl is divided into three areas of responsibility:
* Resources are objects to which access is controlled
* Roles are objects which may request access to one or more resources
* ACLs provide a tree structure to which resources and roles may be added, and which map access rules between them.
Zend_Acl is primarily engineered to be configured and manipulated programmatically. While you can certainly write functionality to pull the information out of a data store — say, an LDAP directory or a database — in many cases, you don’t need to. Let’s look at this simple ACL definition:
Here for the second post.