When to use Modules in Zend Framework?

Question

When setting up new ZF Projects i normaly have this directory structure:

• application
  • modules
    • default
      • controller
      • forms
      • view
      • models
    • admin
      • controller
      • forms
      • view
      • models
  • language
  • shared
    • models
• library
• public

I use only modules when e.g the layout is diffrent, or a diffrent database is used, or of course when its a very special case like a admin-backend or a forum/board. Then i have Controller for the different parts of the application. e.g JobController, ProductController and so on.

A colleague of mine showed me his base layout. its nearly the same, but he uses a lot of modules. like Job-Module, Product-Module each of this modules mostly have 2 Controllers an IndexController and an AdminController.

His setup works and isnt wrong, but i never saw such an approach, its seems unneeded complicated.

So to come to an end:

1. When would you use Modules and when you would stick to Controllers?
2. Whats your rule to decide Module or not Module ?
3. What are the cons AND pros of my colleague's setup in your point of view?
4. What are the cons AND pros of my setup in your point of view?

TIA

Rufinus

EDIT: see http://mwop.net/blog/2012-04-30-why-modules.html for info on the redesigned modules in ZF2.0

Answer 1

What are the cons AND pros of my colleague's setup in your point of view?

Better Reusability. Assuming your colleague kept the code inside the modules indepedent from other modules, he effectively created a self-contained problem domain. Unlike with your approach, he can more easily copy the entire module over to other applications then.

Answer 2

...like Job-Module, Product-Module each of this modules mostly have 2 Controllers an IndexController and an AdminController.

That description kind of raises a red flag to me. IF this was a really big project that needed to rely on high resusability and IF he coded such modules in a way that they could work independently of other modules in the the system and IF there was a need to isolate the admin area for each module, then this could be considered a reasonable approach.

But I would assume there's likely a dependency between Job and Product, in which case, this module approach sounds like over-engineering. Especially if there seems to be an arbitrary 'rule' being enforced (like one business object per module).

Also, most MVC frameworks would assume that if you have Job and Product models, you have Job and Product controllers (not an IndexController for each entity). The purpose of modules is to segregate logical and presentational areas of your site, not divide up business logic.

While it's probably neither here nor there as far as proper MVC is concerned, it doesn't make sense to me to create a module that cannot operate fully independent from other modules.

Answer 3

Q) When would you use Modules and when you would stick to Controllers?

A) For me its all about the size of the application. When you have more than say 10 controllers you might want to think about refactoring some of them into a separate module. If you are planning on building a REALLY BIG application it may be worth spitting it up into modules before you start.

Q) Whats your rule to decide Module or not Module ?

A) Like I said having more than 10 controllers.

Q) What are the cons AND pros of my colleague's setup in your point of view?

A) If it is a small project he is over engineering it which will make it harder for other developers to jump into and will take him longer than needed to develop in the first place. He also runs the risk of confusing himself.

Q) What are the cons AND pros of my setup in your point of view?

A) My answer above pretty much covers it, if it's a smaller project your way will be quicker and less confusing in the long run. I prefer this approach and just re-factor if the scope is increased.

Answer 4

When would you use Modules and when you would stick to Controllers?

Same as you. For major sections of my website like the front-end, admin section, members section, etc...

Whats your rule to decide Module or not Module ?

Is it part of the main site or its own little world just related to the front end? Especially in regards to design. How do you manage a couple of modules some using the same layout?

What are the cons AND pros of my colleague's setup in your point of view?

My God the maintenance. All these folders for nothing at all. Why have your about page and contact page in two different file structures? Also where does he put admin and members if he uses modules for simple pages?

What are the cons AND pros of my setup in your point of view?

Really the opposite of the above. Easy to understand and coherant structure.

Its worth it to add its the way the zend team intended us to use it link

Another thing to think about is what will your urls look like.

myapp.com/contact

myapp.com/about

myapp.com/members/profile

myapp.com/members/profile/edit

myapp.com/members/mail

This is one easy way to help organise what will go in modules or controllers.