打包通用zend模块的最佳方法

Question

As our company starts using Zend Framework as the base framework for most of our projects, we want to share some common elements across all our projects. I talk about things like:

• An implementation of a model (based on doctrine2)
• RBAC for the model, including user, group, role models
• A xml-based templating engine for ajax backend interfaces
• (you name it) ...

Basically, all things to put "zend on rails" and get going. What is the best way to package these components? I see two possibilities:

As modules

We include the necessary functions as separate modules into the modules folder.

Pro:

• We can set routes and execute code, which is good for many modules (imaginary example: a paypal module needs some kind of callback url. If our module can set it up on its own, no configuration from the "project developer" is needed).
• We can provide real functionality (like the user administration) out of the box
• We have a bootstrap to set up autoloading and doctrine etc.

Con:

• Bad place? Interferes with the users project
• A little harder to share between projects (git submodules instead of classpath)

In the library folder

We put it in the library folder and point the classpath to it.

Pro:

• Clean solution
• Sharing across projects

Con:

• Bootstrap has to be explicitly called
• No direct routing or actions - everything has to be proxied through the concrete project

So, how do you solve this? Where do you put your reusable, general purpose stuff in zf?

Answer 1

I think you should use both approaches.

When developing "library-like" code, as in kind of "infrastructure" classes and other things that are reusable (like ZF's own components, Doctrine 2's components etc.), you can put them into the library directory. (or its own entirely separate project)

When developing actual ZF modules (like an auth module for example), then format the code around the ZF module structure.

I think by using this kind of approach you get all the benfits you listed, and pretty much none of the cons :)

As one additional idea, if you develop your architecture parts as "services", you could even keep them running as their own web service endpoints.