I’m building an application in PHP, using Zend Framework 1 and Doctrine2 as the ORM layer. All is going well. Now, I happened to notice that both ZF1 and Doctrine2 come with, and rely on, their own caching implementation. I’ve evaluated both, and while each has its own pro’s and cons, neither of them stand out as superior to the other for my simple needs. Both libraries also seem to be written against their respective interfaces, not their implementations.
Reasons why I feel this is an issue is that during the bootstrapping of my application, I have to configure two caching drivers – each with its own syntax. A mismatch is easily created this way, and it feels inefficient to set up two connections to the caching backend because of this.
I’m trying to determine what the best way forward is, and would welcome any insights you may be able to offer.
What I’ve thought up so far are four options:
- Do nothing, accept that two classes offering caching functionality are present.
- Create a Facade class to stick Zend’s interface onto Doctrine’s caching implementation.
- Option 2, the other way around – create a Facade to map Doctrine’s interface on a Zend Framework backend.
- Use multiple-interface-inheritance to create one interface to rule them all, and pray that there aren’t any overlaps (ie: if both have a “save” method, they’ll need to accept params in the same order due to PHP’s lack of proper polymorphism).
What option is best, or is there a “None of the above” variant that I’m not aware of?
3
Do nothing Accept that separate projects can have redundancy as long as they work in their own spaces (not polluting each other caches). Doctrine knows Zend has caching but they don’t want to be dependent on Zend and vice versa. Not all people want to use Zend and Doctrine.
I’d let Doctrine code use its own stuff and use ZF for everything else. This way I only need to know ZF classes. Doctrine cache should only be used internally by doctrine for database object. ZF has more front end that’s useful outside an ORM, like html page caching front end.
Creating another layer would be ideal but it’ll add another dependency to the project, so not very good for maintenance.
I know that in bootstrap it can look redundant to setup multiple caches. It can get worse if you try to use ZF1, Doctrine and ZF2 simultaneously. But it’s a very small constant time as they only setup variables, not connecting to the back ends yet.
So, from programming, maintenance and operation perspective, I’d just leave them alone.
Reasons why I feel this is an issue is that during the bootstrapping of my application, I have to configure two caching drivers – each with its own syntax. A mismatch is easily created this way, and it feels inefficient to set up two connections to the caching backend because of this.
Why not just tackle the issue from a “make configuration more convenient” standpoint?
In other words, write some new class that accepts your configuration data, and then applies it to both caching drivers. Sure, it isn’t as flexible, but that also means less can go wrong.
Why not creating an abstraction of your interface that can be specialised to each of the frameworks? I would write my own cacheing Controller with methods I need, that would encapsulate both caches. Then I can forget about them and only talk to my Controller. Any problems with that solution?