8

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

package1
  Class1Controller
  Class1Model
  Class1View
package2
  Class2Controller
  Class2Model
  Class2View

or 

controller
  Class1Controller
  Class2Contoller
model
  Class1Model
  Class2Model
view
  Class1View
  Class2View

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.

SteeveDroz
  • 675
  • 3
  • 8
  • 15

2 Answers2

6

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:

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

Falcon
  • 19,308
4

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.

Flot2011
  • 2,192
nobs
  • 156
  • Do I understand your answer correctly: "If you have a good reason, use number 2, but by default number 1 is better" ? – SteeveDroz Oct 21 '11 at 08: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 06:56