MVC in Windows Environment

[BBirkett]

Hey everyone,

I need a design pattern expert to help take me over the line here.

I think i have quite a good understanding of the theory of the Model View Controller pattern after reading a dozen articles on the topic - here is my understanding so far and please correct me if i'm wrong anywhere:

Model: encapsulates the data you want to model and provides methods for changing the models state. Notifies all observers (views) when it has changed.

View: the output of the model as a view into the system.

Controller: handles input usually via keyboard and mouse, updates the model and changes the view.

An example i thought of to explain my understanding would be a 3D house rotating program. The program could use a joystick to let the user move around the outside of the house. The model would be the data required to render the house such as points and vectors, current camera position etc. There could be multiple views outputing to a monitor at the same time - one for front view and one for top view. The controller could be an object that listens to the joystick events and manipulates the model as required, ie. moving the models current camera position.

What i mostly don't understand is how to implement this model in a Windows environment. I'm looking to build an example using c# and windows forms.

My problem mostly lies with data input for business applications - like a job form for adding a new job for a client. I'm having trouble understanding the roles of each object in this scenario. My guess is that the model would be the client and job data and methods to save and load from a database. The view would be the user interface displaying all the text boxes. The controller would recieve events from the view, ie. notifying when a save button is clicked. The controller then could somehow get the data from the view and use it to update the model and save to a database.

Questions:
---------------------------------
1. For the controller to get the data from the view, it has to have access to all of its textboxes, or at least accessor methods.

a. Wouldn't this be inefficient - especially if the modules are distributed on different machines?

b. How can we let two views use the one controller? ie. the first view might be windows forms which HAVE textboxes, but the second view might be a console window which does not.

2. Is data validation done in the controller or the model?
- if its done in the controller, then it would be good if multiple views could make use of it.

3. If textboxes are rendered in the view object, then how can the controller be the object that is listening to the keyboard and mouse - A textbox control automatically displays data as it is entered from the keyboard. The only way i can see is that the view notifies the controller when important events occur.

4. The controllers job is to update the model and change the view - what does 'change the view' mean?
a. Physically change the colour of a textbox on the view directly.
b. Ask the view to change the colour through a method call.
c. Load a totally new view object?

5. I've read other examples where the controller object renders the input screens, and the view object renders the output screens - but what if they are both the same screen? And how can we then reuse the controller objects validation across multiple views?

Thank you to anybody who can help me get through these questions.


Brett Birkett B.Comp
Systems Analyst

 

[palbano]

Ok first patterns are not some mystical things that hold all the answers nor do they make everything just work. Ummm especially the MVC pattern which is totally natural and not a big deal at all. Think of it in much simpler terms.

If you used a SQL database in your application you wouldn't put the code to access the database in the same class that paints the UI would you.

That's all it's about really don't over complicate it. It really just suggest 3 categorical separations at a high level in your OOD. It does not mean you only need 3 classes to implement it. You still have to do all the OOAD.


-pete

 

[Polu]

Hello, Brett and Pete.

IMHO there is a mistake in your post: The controller won't receive events from the view, the controller receive events from the input hardware (wrapped by the OS).

So, here are my answers:

1a) Yes, there is an overhead using MVC pattern, but MVC provides advantages in code reuse. It's your decission as a Software Architect when to use it.

1b) Views don't use controllers. Controllers receive events, process it and maybe alter the Model. Then, the Model will notify Views, which could change (or not) it state to let the new Model state to be noticed by the User.

2) Data validation is done in the Model. So you use the Model in all your views.

3) In a windows-like environment, the form contains the view and the controller. TextBox1.Text, RadioButton1.Checked and all this stuff belongs to the view and Button1_OnClick belongs to the controller. But in a console-like environment, there will be a class painting the screen and other class listening the mouse (in example).

4) The controller job is update the model but not the view. The view must update itself whe nofiyed by the model.

5) If your app need a form view, you should consider separate the form from the view and the controller. The form will be invoked by the view class to change the textboxes and the form will invoke the controller and the controller will manage the events.

And that's all. I hope it will useful!

Best Regards.

Polu.