Best approach to separate Model View and Controler

Question

I'm thinking about the best approach to separate Model View and Controler - for Java and using Eclipse, if if it makes any difference.

I used to separate each type's MVC inside its own package, but I'm start to think that this is not the best approach:

• com.company.client (controler)
• com.company.client.model

• com.company.client.view

• com.company.another (controler)

• com.company.another.model

• com.company.another.view

• com.company.yetAnother (controler)

• com.company.yetAnother.model
• com.company.yetAnother.view

(assume a lot of different packages, each one with its own view and model)

I thought about use:

• com.company.client
• com.company.another

• com.company.yetAnother

• com.company.model.client

• com.company.model.another

• com.company.model.yetAnother

• com.company.view.client

• com.company.view.another
• com.company.view.yetAnother

I even thought about put controler, model end view in different projects, Maybe it would be even move modular, and I would have more sure that the view is not using the controler, for example (as the controler project would include the view, but not the otherwise.

So, if its one of this or not, what is the best approach to separate M, V and C?

(consider web and desktop apps, not just web)

Answer 1

Are you only concerned with "separating" the Model, View and Controller as far as naming and packages go? This seems to be all you are asking about.

I tend to lay out my packages as such:

• com.company.app.domain - Domain model classes for the application, simply Java beans (getters and setters only, very little if any logic). This is used as "the model" throughout the application and used by every layer of my application.
• com.company.app.service - Service level classes of the application, containing business logic.
• com.company.app.web.controllers - Controller classes for my webapp. Other web-specific classes are put in various other subpackages of web.
• com.company.app.dao - DAO interfaces for accessing the domain model classes - i.e. to retrieve a User from the database, etc.

Within each of these, packages are sometimes broken down by area of the application or into smaller groups based on functionality, whatever seems appropriate.

Answer 2

I think it is also important to consider how you would like to ultimately utilize the fact you have broken out separate modules in your code base. I.E. What type of utility other than basic code quality are you looking at exploiting based on your packaging scheme.

Most of the apps i work on follow the following packaging structure: *.domain, *.service.subservice, *.dao, *.web.controllers. This works out nicely for tracking cyclic dependencies in the code base and/or dependencies which flow the wrong way ( controller hitting the dao without the indirection of a service ). It also provides a very simple packaging structure which is useful and non burdensome.

However, this breaks down when looking at automated dependency impact assessments. I currently use DependencyFinder with a bit of custom code to compare two jar files before QA. DependencyFinder will pull all modified methods and their associated first level dependencies. Custom code has to kick in to map the modified methods/classes to business functions and spits out a graphviz grammar file for rendering a business function based change-set, dependency graph for QA. We currently attempt to the use the results of the tool for smart regression test planning particularly for production defects which are moving to production without a full multi-week regression test.

The directory structure you propose will make the second case much easier. However, i also found that most of my development team does not really care dependencies at all, so the utility of the auto-dependency checker may vary :)