MVC Pattern

[David Dickinson]

Hi Guys,

Im about to commence development of an application written adopting the MVC pattern. It's my first time using it and i'm spending my first few days reading about it, I haven't used the GUI features in Java before (I have done a large amount of console focused programming in Java) can anyone point me in the direction of some useful guides for MVC?

I have read through a couple of online guides but have found them a little bit vague and sometimes uneccessarily complex.

Thank you!

[Stan James]

Since you reference the GUI features in Java I guess you're building a Swing front-end? See if you can sketch up a short description of the responsibilities of the model, view and controller components, some ideas about how you'll implement them. Scroll down to the UML, OO, etc. forum down the page a ways and post your current thoughts. The gang there will happily critique & help out.

[Layne Lund]

Are you writing your own classes using the MVC pattern or are you using the MVC classes that are already available in Swing? There is a big difference between writing your own classes and reusing ones that are already available.

Layne

[David Dickinson]

I'll be writing my own classes.

My understanding atm is I create a class which defines the GUI and catches the relevant events. The event listeners triggers getters/setters which inturn trigger observer updates thus completing the circle.

Is that correct? Does anyone have a small project they could post which utlises GUI's and MVC?

I also have to follow a TDD approach and thus i've always been advised not to use UML diagrams at the beginning of the project. What would you recommend?

Thank-you!

[Sripathi Krishnamurthy]

FYI..David,
Java Swings use MVC pattern themselves. Means the JTree, JTable, JList and all the GUI components are based on MVC.

you can read it from this link
http://www.cs.cf.ac.uk/Dave/HCI/Exams/HCI98_99_SOLNS.pdf

You will get an idea on how to proceed after reading this.

[Ilja Preuss]

Originally posted by David Dickinson:
Is that correct? Does anyone have a small project they could post which utlises GUI's and MVC?

I also have to follow a TDD approach and thus i've always been advised not to use UML diagrams at the beginning of the project. What would you recommend?

First, I would forget about not drawing UML diagrams. Sketching some UML for some minutes at the start of a TDD session is totally OK. It's just important that you use the UML as a starting point, not as a "specification" that you have to follow.

Second, I'd advice to google for "humble dialog", which is an approach for making it easy to test-drive GUIs. As far as I remember, the articles typically come with nice little introductory examples.

[Jayaraj Sekaran]

Hi... After you read some basics about MVC, have a look at STRUTS framework. It is based on MVC and offers you lot of reusable code which will help you for your development. Check for it in the apache site. It is free to use.

[David Dickinson]

I can't use Struts or any other 3rd party code, all code must be written by myself. Thanks for the suggestion though.

Well I should explain myself a little bit more, at the moment I have a fully working program which is effectively the model, it stores the data in collections and allows methods which update/retrieve data from the collections, it works well.

Now I need to add a GUI to replace the currently console based user interaction.

I'm busy writing my GUI which will interact with the collections.

One part im not sure about is the idea of the controller, what does it do? Is this were I should put my getters/setters?

Thanks guys

[Stan James]

Wow, that's a neat way to have built the thing. I wish we could always think out our models without being bothered by the UI.

MVC is one of those things ... for every person who says he gets it and uses it you'd find a slightly different interpretation and solution. The most important bits I aim for are: the model has no dependency on the view or controller, the view has no logic at all.

My favorite description of controller is it "interprets user gestures". It might get a mouse click and say, "Oh, you want to send a value to the model now" or "You're going to need another panel for that!"

I don't think I'd see any getters & setters in the controller, though there are different mechanisms for sending input from the view to the model. The controller is often pretty tightly wedded to the view. It might know this "user gesture" means to get data from several screen widgets before making a call to the model. Is that the kind of thing you meant?

[David Dickinson]

Stan,

It might know this "user gesture" means to get data from several screen widgets before making a call to the model. Is that the kind of thing you meant?

Not really what I meant.

Am I to presume therefore that the controller is reponsible for calling the getters/setters from the model?

the view has no logic at all

Surely the view must be responsible for user input validation? If a user enters a series of characters into a text field which requires numbers surely the view must be responsible for alerting the user?

Thanks!

[Ilja Preuss]

Originally posted by David Dickinson:
Am I to presume therefore that the controller is reponsible for calling the getters/setters from the model?

I'd rather say that the controller is responsible for translating user gestures (thanks Stan!) into actions on the model. Those actions will likely include calling some getters (if the users wants to put some values into the model), might include other things and are unlikely to include many calls to getters.

Surely the view must be responsible for user input validation? If a user enters a series of characters into a text field which requires numbers surely the view must be responsible for alerting the user?

The view would be responsible for *alerting*, but not necessarily for validation. I'd rather say that the controller should validate the input values, and then either tell the view to alert the user, or pass the values along to the model.

But things aren't always that clear cut. For example, it might be even better to build the view in a way to not accept invalid values at all (for example by using a JFormattedTextfield).

[David Dickinson]

Originally posted by Ilja Preuss:
Those actions will likely include calling some getters (if the users wants to put some values into the model), might include other things and are unlikely to include many calls to getters.

Did you mean to say the controller might include some setters but not getters?

If so why does it not include the getters? In which case where are the getters called?

Thanks

[Steven Bell]

I think this gets further confused because there are several MVC patterns within a single Swing app at different levels. I don't think there are any wrong answers as far as validation goes, you just need to pick at what level is this input validated to a certain degree.

Example:

Lets say you have a window that allows a user to enter a credit card number, 4 text fields of 4 characters each, and a drop down for the type of card (Visa, MC, ect..).

Each text field and the drop down encapsilate the MVC pattern by themselves. In this case the drop down makes invalid selections impossible, but each of the four text fields can verify that they have 4 digits in them before allowing the user to move to the next field.

At the Form/Window Level we have another MVC pattern that has, as part of it's view, the other components. We can make this form level responsible for validating that there are 4 sets of 4 numbers in out text fields on a submit before the allowing the model to be updated.

Assuming this is part of a larger app we could have another level that actually checks that the credit card is valid.

So in this example we have 7 MVC patterns nested within each other. It's a matter of defining responsibility and scope.

In the big picture your Swing UI is the view, your program that your writing this GUI for is the model, and there will be a controller to handle the communication.

[Stan James]

There are a number of implementation solutions for getting data back into the view. One option is for the view to subscribe to "data changed" events from the model. This does not give the model any dependency on the view because the model owns the interface that the view must implement to get messages. In some systems the "data changed" event includes the data while in others the view has to call the model to get the change. There may be others that send the data via the controller, but I haven't done that myself.

Here's something I had laying around for data change event with no data on it:

     View      Controller     Model
 ------------ ------------ ------------
 
      SearchButtonPressed
      +------------>
                   ExecuteSearch
                   +------------>
      DataChanged
      <-------------------------+
      GetSearchResults
      +------------------------->   

You have tons of options for validation, too. The model has the responsibility to check everything coming in because it has a "trust no one" attitude. Smart widgets on the view can have their own internal MVC thing going on as described above. That can give very cool user experience, but runs the risk of duplicating validation done in the model. In the web world model validation happens only on a server call (POST, GET, etc) and might not be slick enough for the user.
[ April 19, 2005: Message edited by: Stan James ]

[Ilja Preuss]

Originally posted by Stan James:
There may be others that send the data via the controller, but I haven't done that myself.

That would then go into the direction of the Model View Presenter pattern. I have sometimes done that, because it allows to test the whole presentation logic without having to touch Swing code at all.

[Ilja Preuss]

Originally posted by David Dickinson:

Did you mean to say the controller might include some setters but not getters?

No, I was talking about the controller *calling* them on the model. In my experience, a controller typicall doesn't have any setters or getters at all, but uses the Observer pattern to communicate with the view and simply delegates to the model.

[Andy Rayner]

Originally posted by David Dickinson:
[QB]
Is that correct? Does anyone have a small project they could post which utlises GUI's and MVC?

/QB]

I have a simple one called flipper, i have put it up on my webspace so you can download it and take a look, its uses a GUI, MVC and Observer/Observable



Flipper

just incase you are still wondering

[David Dickinson]

Andy,

Just wanted to say a big thank-you that Flipper program has made every thing much more understandable, its well worth a look should anyone have problems understanding MVC.