When to use Modules in Zend Framework ?

Answer 1

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.

Answer 2

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 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

...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.