The best approach to a single model, view and controller

Question

I am thinking of a better approach to a separate model view and controller - for Java and using Eclipse if that matters.

I used to separate each type of MVC inside my own package, but I'm starting 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

(take many different packages, each of which has its own look and model)

I was thinking about using:

• 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 putting the controller, model and view into different projects. Perhaps it will be even more modular, and I'm sure that the view does not use the controller, for example (since the controller project will include the view, but not vice versa).

So what is the best approach for separating M, V, and C?

(consider web and desktop applications, not just web pages)

Answer 1

The Graal Quest! You have a two-dimensional matrix with vertical (MVC) and horizontal (business rules) levels ...

• I did not find a strict answer
• Your first approach looks good because modular oriented (unforeseen)
• For a small application, your second, although perhaps acceptable

For me, the answer is the word: dependencies
Continue your search in “design / packaging strategy”; "Grain"

Some reading

• http://techdistrict.kirkk.com/2009/08/05/modularity-patterns/
• http://techdistrict.kirkk.com/2010/04/22/granularity-architectures-nemesis/

I highly recommend this:

• http://www.jgoodies.com/articles/patterns-and-binding-old.pdf

LUCK!

Answer 2

Assuming you have to deal with a non-trivial project, I think that your problem has two aspects that need to be considered together to configure the architecture and quality of the code:

• naming
• modularity

For naming purposes, I try to have the highest grip in each namespace and follow the General Closure Principle and the General Reuse Principle .

For modulation, I try to use a module for each architectural main problem of the project and it is convenient to use its packages.

MVC is a presentation module template that aims to separate how the presentation module controls the flow, which data models it is based on, and which is the logic associated with the presentation.

In my java IDE (e.g. Eclipse) I use a project on a module, so the web module will be a project and the desktop will be another project. In a web project, for example, I have a common prefix, for example:

com.mycompany.app.web 

and in it I have .controllers (or actions) a descendant, a descendant of .models, etc.

 com.mycompany.app.web.models com.mycompany.app.web.actions 

If I use a database, I rely on the DAO module, another project. The DAO module does not have a presentation, so it does not have an MVC approach. It saves domain objects, so maybe it relies on a domain module. In these modules, I use prefixes as follows:

 com.mycompany.app.domain com.mycompany.app.dao 

I try not to confuse the Model in MVC with the Domain application; they are not the same thing.

Another common mistake is the controller confusion with business logic ; business logic should be placed in a module and shared through presentation modules, a controller in the namespace of the presentation module (website or desktop).

A Model (in MVC, a view model) is an object used by a view to show something to the user: it can contain one, a combination, or a collection of Domain . The controller uses the available modules (DAO, etc.) to create the Model view, and then passes it to the View .

View , then you can rely only on the Model (only one explicitly created by the controller) and request models only for controllers (only for models). Viewing , especially for web presentations, is often encoded in a combination of languages, so part of the code may remain outside of naming conventions.

Answer 3

Do you consider only the “separation” of model, view, and controller for naming and packages? This seems to be all you ask for.

I try to lay out my packages as such:

• com.company.app.domain - domain class classes for the application, just Java beans (only for getters and seters, very few if there is any logic). This is used as a “model” throughout the application and is used by every layer of my application.
• com.company.app.service - application service level classes containing business logic.
• com.company.app.web.controllers - Control classes for my webapp. Other web-specific classes are placed in other web subpackages.
• com.company.app.dao - DAO interfaces for accessing domain model classes - for example, for retrieving a user from a database, etc.

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

Answer 4

I think it is also important to consider how you would like to ultimately use the fact that you broke up individual modules in the code base. I.E. What type of utility differs from the underlying quality of the code, you are looking at using based on your packaging scheme.

Most of the applications I'm working on follow the following packaging structure: * .domain, * .service.subservice, * .dao, * .web.controllers. This works well for tracking circular dependencies in the code base and / or dependencies that do not work correctly (the controller gets to dao without the indirectness of the service). It also provides a very simple packaging structure that is useful and not burdensome.

However, this breaks down when considering automatic estimates of dependency effects. I am currently using DependencyFinder with a bit of custom code to compare two jar files before QA. DependencyFinder will pull out all modified methods and their associated first level dependencies. The user code should be used to display the modified methods / classes in the business function and splash out the graphviz grammar file to render a set of changes based on the business function, dependency graph for QA. We are currently trying to use the results of the tool for planning intelligent regression testing, especially for manufacturing defects that go into production without a full weeks-long regression test.

The directory structure that you offer will make the second case a lot easier. However, I also found that most of my development team doesn't care about dependencies at all, so the auto-dependency checker may vary :)

Answer 5

Here is an example using the Layered Architecture construction with three layers (application, domain, ui):

In model-view-controller (MVC), the model will be in the lower layer, for example com.company.myapp.domain . All other layers can access the Model. Then View and Controller will be in com.company.myapp.ui . This means that the Controller class is always at the same level as the View . Do not confuse MVC-Controller with other controller classes that provide application logic and are at the application level. For example, SalesController at com.company.myapp.application , which provides system operations for processing sales.

Now you can imagine that SalesController modifies some data in your model (updates the sale), and then the model informs the MVC controller, which updates the view.

Note. All models are at the domain level. All MVC views and controllers are at the ui level. Business logic controllers are at the application level. Of course, you can separate these three layers further if you have many classes with various problems.

Hope this helps.

Answer 6

Think about how you are developing. Do you develop each controller / model / view? Or you design for each module. Most likely, you are developing a module, not at the MVC level. Therefore, I think there is an answer. Try to keep the package names as close as possible to the modules your system represents (which you already do, I suppose). No need to show you architectural options in package names.

Displaying module names and domain problems in your package creates a supported and consistent code base.