Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I have been programming quite a lot now and still can't decide which of these packages hierachies was the best:




In other words, is it better to apply the MVC design pattern to classes or to packages? Is there any reason to choose one over the other?

My question is language-agnostic, but I'm mostly a Java programmer, if it does any difference.

share|improve this question

marked as duplicate by Florian Margaine, gnat, MichaelT, GlenH7, BЈовић May 28 at 5:11

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers 2

up vote 2 down vote accepted

Short Answer: It depends :-)

Normally I would recommend your first suggestion because you put stuff in a package which belongs together. In your second example Class1Controller and Class2Controller may have nothing in common except that they are controllers.

But as I said in the beginning, there may be a reason to use the second pattern instead the of the first.

share|improve this answer
Do I understand your answer correctly: "If you have a good reason, use number 2, but by default number 1 is better" ? –  Oltarus Oct 21 '11 at 8:42
Yes, but beware: having a good reason is highly subjective! –  nobs Oct 21 '11 at 10:32
@nobs: There's nothing subjective. It's a matter of architecture and the second option is clearly worse to the first one. The second version is a naive approach to program organisation. It does not yield any technical benefits. –  Falcon Oct 21 '11 at 22:27
@Falcon: If humans are involved, everything is subjective! It can have benefits if the models/view/controller are tightly coupled. I don't say that this is a good solution only that there are cases the second option may have its benefits. –  nobs Oct 23 '11 at 6:56

In general you should divide your application into functional packages rather than structural ones. What use is, for example, a business exception ("Order not found" e.g.) in a general exceptions package?

You should have a high cohesion within packages. I'd rather split a single package into several layers than dividing them by their structural/architectural purpose. For example, I believe that the model deserves an own layer with all its necessities. Then, for the specific model, I'd have an application layer with controllers and possibly another exchangeable layer with views, all tied together with well defined interfaces.

Your second option clearly leads to an architecture where many parts of your application will have unecessary and unwanted dependecies. This will limit your flexibility and extensibility options. Just think about it: Whenever you change a single interface in the model package, all packages that use this package need to have an updated dependency as well.

In short, I'd structure a basic application like this:

   model        (subpackage/assembly, contains the business logic)
   application  (subpackage/assembly, contains controllers etc)
   presentation (subpackage/assembly, contains views etc.)
   interfaces   (optional, encapsulates well defined interfaces 
                  so the layers can communicate and for Dependency Injection)

The layers can be namespaces of physically distinct. Physical distinction (compiling to different Dlls) really helps to keep your architecture clean, the interfaces part can be a gatekeeper.

Also be aware that the term model can mean different things. Model can refer to business logic (in OOP mostly an object model of your business domain) or to a single "presentation model (at this point I don't refer to Fowler's pattern 100%, but rather to the myriads of MVC variants in general)". While the first one truly belong to the model package, the latter one belongs to the application layer. I like MVC best when the controller just calls the business logic and the persistence layer. Most of the time it doesn't need a separate model.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.