Layer 1: DB interface ( provided by sun ) and then a Data class which implements these methods. Provides actual I/O to the database.
Layer 2: A business layer of sorts. An abstract class called something like DataBaseService defines read/write/update methods that delegate to the Data class. Then sub classes are created which are tailored to either a local or remote approach. So you would have say, LocalDataBaseService and RemoteDataBaseService. A Factory would be created to return the appropriate implementation in your view layer. The client ( the view code ) would never know if its using the Local or Remote version. It just knows its using a DataBaseService.
Layer 3: The GUI layer. For the SCJD it is in SWING, but could be in HTML or some other GUI technology. The view would use the Factory mentioned in the previous paragraph to instantiate an instance of DataBaseService. The "action listeners" or some other event processor would fire methods in DataBaseService to perform database operations. The DataBaseService could possibly implement Observable, so that GUI clients could implement Observer ( and add the instance of DataBaseService to its observables list ) and update the GUI when notifications are passed along.
is this design considered MVC or some other pattern? It looks like layer 1 could be the model, layer 2 the controller, and layer 3 the view.... or am I mistaken? A friend of mine says this is not MVC. He says all it is is the Adapter pattern ( layer 2 ). He said Layer 1 and 2 are not much different from each other- and are not clear model and controller layers.
Kenny Johnson wrote:is this design considered MVC or some other pattern? It looks like layer 1 could be the model, layer 2 the controller, and layer 3 the view.... or am I mistaken?
Depending on the details of implementation, the three layers you describe could be considered either an example of Model-View-Controller or an example of Model-Delegate. It would be normal for the business layer and data access layer to comprise the model, but this can be achieved with different degrees of entanglement and different loci of control.
A friend of mine says this is not MVC. He says all it is is the Adapter pattern ( layer 2 ). He said Layer 1 and 2 are not much different from each other- and are not clear model and controller layers.
The Adapter pattern allows one object to consume the services of an incompatible provider through a mediator object that provides the API the consumer expects and then translating that (byfm) into API calls on the provider.
In a strict sense, your friend is mistaken; he's applying to an entire application architecture the label that fits properly only on the reconciliation of two incompatible classes.
On the other hand, your friend is right that there's an adapter-like character to the C in the MVC pattern. It reconciles the expectations of the presentation layer to the provisions of the service layer.
But this is trivially true of all programming that achieves loose coupling via interfaces and separation of concerns. All non-brittle software consists, in some broad and perhaps metaphorical sense, of adapters that serve as Babel-fish in the ears of otherwise discrete agents.