Is this considered MVC?

[Kenny Johnson]

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]

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]

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]

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.