Behavior driven development
You may know that Propel allows to define behaviors. Up to recently, I used to think behaviors just added cool features to my models. It took me time to realize that in fact, behaviors allow my models to have a uniform API. In this article, I'll expose how to define application scoped behaviors, but also how you should extend existing behaviors.
Extending existing behaviors
Versionable is definitely a cool feature. It's easy to use, quite transparent, and it does its job : keep track of the entity modifications. But how can you keep track of who made the changes? Should you set the created_by fields in every place your application saves an object? And what about the behavior configuration? Should you repeat it in every table?
The answer is obviously no, remember the DRY principle. So, how can you centralise this code and configuration in a better place than in MyApplicationVersionableBehavior?
Extend the original behavior, override the parameters property, define a preSave() method retrieving the current user, and from now on just focus on your business logic!
Creating application behaviors
If you use an ORM and a framework, it usualy means that your application requires a specific business logic. Most of the time you may feel like repeating yourself in different models, for pieces of logic concerning resource access policy, object image...
These are perfect candidates to become behaviors, as the API will be unified for every objects. The good thing is that logic is coded once, tested once, and available everywhere...
Oh, and if your behavior can be shared, just do it, it might avoid people from reinventing the wheel. Who knows, if there are enough shared behaviors, maybe Propel2 will provide a way to simply manage external behaviors!
4 comments
maybe you can find something interesting in https://github.com/Carpe-Hora/ClassifiableBehavior that is a Resource Access Layer.
