Java – MVC – sharing multiple models

javamvc

I am building a java desktop application where I am attempting to implement MVC. The GUI interface has multiple views (think pop-up windows) from the main view. Each view has its associated model that it receives updates from.

I am running into scenarios where two views need to access a particular data field from one model. This requires that one model "knows about" the another. What are my options to solve this?

The data field is a table that is populated in one of the views and is then subsequently accessed in the main splash view.

I have tried passing the second model into the first's constructor from the controller, however I feel this is sloppy. Should a model listen to another model (Observer pattern)? Perhaps my question is too subjective….

Best Answer

Single model and multiple views - I see no problem in your case. Have you tried to implement observer pattern? If not, try to write your classes according to class structure suggested by observer pattern. I think it will solve problem.

You can visit here to find more information about observer pattern.

Related Solutions

Mvc – In MVC + SOA Architecture, What is the Rationale for Placing Business Logic in Models

The Model-View-Controller pattern is a UI pattern that follows a few basic principles:

The View is a User Interface, a thin veneer in front of the Controller. The only logic that should be in the View (i.e. "Code-Behind") is that logic which pertains directly to interacting with the user.
The Controller is a thin veneer in front of the Model. It acts as a switch-yard, shunting requests from the View to the Model for processing. The only logic that should be in the controller is logic that facilitates this communication.
The Model contains everything else about your application, including your Data Access layer (in your case Dapper or Entity Framework Code), your Repository Layer (which includes Entities and CRUD methods), and your Business Logic Layer.

The overall architecture so described looks something like this:

Database --> Data Access Layer --> Repository --> Business Layer --> Controller --> View

The arrows indicate the direction of the dependency knowledge; e.g. the View knows about the Controller, but not vice versa, and so on.

The Business Layer can be thought of as a CRUD/Business Transaction converter. On the left side, it speaks Create, Read, Update and Delete, using entities from the Repository. On the right side, it speaks business operations (things like "Print an Invoice" or "Bill a Customer), using what I would call View Model objects. These View Model objects are what the Controller uses to glue the UI to an underlying data representation.

Note in my example how the Business Layer has been abstracted from the Controller. This allows you to use different controllers with the same Business Layer.

Best Answer

Related Solutions

Mvc – In MVC + SOA Architecture, What is the Rationale for Placing Business Logic in Models

Related Topic