wood burning stoves 2.0
The moose likes OO, Patterns, UML and Refactoring and the fly likes Is this considered MVC? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is this considered MVC?" Watch "Is this considered MVC?" New topic

Is this considered MVC?

Kenny Johnson
Ranch Hand

Joined: Jan 01, 2007
Posts: 37
I have 3 classes:

1 ( model ). DataBase - this class performs low level read/write/delete operations on some type of database ( specifics not important ). I consider this to be the model layer.

2 ( controller ). I have a Service class. This class implements Observable. It also defines read/write/delete methods which a client will use to interface with the database. It delegates the actual work of these actions to the DataBase class.

3 ( view ). I then have a GUI SWING class. It implements Observer. This class uses an instance of Service to perform database operations and get notified of events. It adds the instance of Service to its Observables collection so that when events in that class take place, the GUI can update accordingly.

I'm wondering if a deign such as this can be considered MVC. This application is just for my own use to learn design patterns.
Matthew Brown

Joined: Apr 06, 2010
Posts: 4543

I wouldn't call that an MVC. In a true MVC the view would have no knowledge of the controller. It might observe the model, and respond to changes in that, but it wouldn't observe the controller.
Sai Hegde
security forum advocate
Ranch Hand

Joined: Oct 26, 2010
Posts: 204

I agree with Matthew. The view has to be ignorant of the controller. Maybe what you'd need is it to provide methods for registering a Controller's listeners.
Based on the user request, the Controller calls methods in the View and Model to accomplish the requested action.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
In practice, there is usually a significant relationship between a View and a Controller. The View represents how a human user will interact with the Model application. The Controller mediates communication between the View and the Model. All activities are started from the View, i.e. the human user. The View sends data to the Controller and receives data from the Controller.

The purpose of the pattern is to separate and eliminate code dependencies between the Model and one or more Views. Ideally, all functionality in the Model application should be able to be executed from a command-line. And from a code perspective, nothing in the Model is dependent upon anything in one or more Views or one or more Controllers.

Aside, the Model-View-Controller design pattern, and design patterns in general, are suited for large systems with many, many objects interacting with each other in many complex ways. The benefits of designing the application with known and well-thought design patterns are truly realized when the application is large.
I agree. Here's the link: http://aspose.com/file-tools
subject: Is this considered MVC?
It's not a secret anymore!