Module-based projects: when to use them or not use them

I'm starting to familiarize myself with using the module-based architecture for zend framework projects. My real reason behind being interested in the module architecture is to be able to take a module from one project and just drop it into another project. Maybe I'm not getting it right..

But what I'm noticing right off the bat is that controllers within each module cannot have the same name as any other controller in the main application (or in any other module, though I haven't tested this). This leads me to think that modules are not really independent self-contained units, so I wonder how this affects their ease of dist开发者_Python百科ribution from one project to another.

The other issue is what if I were to take a module and drop it into another project. Do I have to update the .zfproject.xml manually? and wouldn't that be a bit too cumbersome to be done manually?

Maybe I'm not clear on how modules should be used in zend, so I'd like to know when you decide it's best to use them, and when do you decide not to use them, or do you use them all the time, or do you never use them?

I always used module based architecture so far in my projects, because I like to separate concepts. For example I have always an ADMIN module whose classes and controllers dont mix with the rest of the application. Using modules you can reuse modules for other applications, for example if you create a BLOG module.

The names of your controllers will be something like Admin_IndexController for the admin module even if the file is named IndexController.php.

Another concept that is nice and help you reuse resources is the plugins. Use them for authentication or to check validity of the requests.

You need to setup namespaces for your modules so that they are easily moved into a new project without renaming.

If you are using Zend Tool then you will have to edit the zfproject.xml. I haven't spent a lot of time using this so I'm not sure if there is another way without manually editing.