MVC implementation wondering
Hey guys,
I am currently playing with a j2me application. I am (of course :) ) implementing an MVC pattern and as I have little experience I was wondering:
How would you implement the model internal state?
I mean the application would normally have more "screens" which belong actually to one view (for my target device) and eventually other screens will belong to another view (for another target device). The controllers call services of the model and it should update its views. But I do not want to keep something like "currentScreen" in my model as it may be different in the different views. The nearest solution is to use some final static ints for a "state" of the model, which I could push to the views, which then can load the correct screen according to that state. But I am not sure that's pretty. The update() methods will than have to switch through all the states. And other than that what will happen if some bad, bad class calls an update method on one of my views with some state that should actually not follow the current? (Well actually I can prevent that using a pull instead of a push...)
But still, is this way with the states ok or I need to rethink stuff...?
[1216 byte] By [
mspa] at [2007-11-26 19:19:34]
# 1
The model should contain (most) of the data the views/screens will display. If you find yourself having to track things such as 'current page' or other view-dependent data, put those variables in the controller. The model should be agnostic to the view and controller.- Saish
# 2
> How would you implement the model internal state?
The Model should always know what "state" it is in. One or more variable fields should suffice.
A variable named "currentScreen" is not appropriate in the Model., as you mention.
The Controller will always have access to the "state" of the Model. Logic for determining what "screen" is loaded based on "state" of the Model goes into the Controller. The Controller and this J2ME-based View are tightly coupled.
If you wanted to use the Model with another View, say a Swing GUI, all you need to do is create another Controller and the Swing GUI. Nothing in the Model should ever need to change because of switching a View.
The Model does not contain any "presentation/display/view" logic, or any "presentation/display/view" data.
If the "state" is clearly related to the Model, it should be implemented in the Model.
If the "state" is clearly related to the Presentation layer and the GUI, then the "state" should be implemented in the Controller.
It depends on what "state" is and how it is used in the application.
# 4
Sounds good.
The application's business/domain requirements are implemented in the Model.
The application's presentation/display/GUI requirements are implemented in the Controller and the View. Low coupling is maintained between the Model and the other components. The View and Controller have high coupling.
