views:

240

answers:

1

Just curious as to how people are tackling multi tenancy using Zend (particularly directory structure, database, modularity, per tenant views, etc.). I haven't found too much myself, anyone?

+3  A: 

It takes a little work, but it's doable. I'm not sure how much my approach follows the strictest definition of multi-tenancy, but in case it gives you some ideas:

I have one installation of my application, which largely follows the recommended project structure (http://framework.zend.com/manual/en/project-structure.project.html). I then have one ZF app per site using the application. These each include a symlink to the main application (currently in the library folder, although this may change). The site apps each use the main application's bootstrap class, but they have their own config files.

The application includes a large number of modules, each of which may or may not be enabled on each site. I have an _initModules() method in the bootstrap which queries the database to work out which modules should be enabled. These are then bootstrapped in the normal way.

It's possible to add additional view paths (which are checked in order) to Zend_View, so a site adds its own view path to the stack. This way sites can easily override views that are in the main application. It would also be possible to add a site-specific model directory to the include_path, which would allow sites to override application models, although I haven't found a need for this yet (and there would likely be a performance impact).

Tim Fountain
Thanks for the reply, that's an easy approach to start from. Also, not really specific to Zend, but do you have a database per tenant? There seems to be a lot of debate over whether a separate or shared db is best and I'm just curious as to what people are actually doing.
rr
I have a separate db per tenant. I think the answer to that question is largely application specific, but generally unless you need to share large amounts of data between tenants, it seems much easier to me to have separate databases.
Tim Fountain