Model View Controller Questions

The classic example of a MVC is a sensor that reports data which is used in a user interface. Suppose, for instance, that you have an electronic thermometer that sits outside your window. It reports the current temperature once per second.

The model encapsulates the software model of the sensor, the means by which the data is accessed, and the data reported by the sensor itself.

There is more than one way to interpret data, however. It is the job of the view component to display the data in a suitable form. For instance, you could have a text box that shows the current sensor temperature, or you could have a graph that shows the temperature over the last 60 minutes.

The controller handles changes or responses to either the model or the view. For instance, one controller might perform a certain action when you click on the current temperature in the view (say, allowing you to calibrate the sensor), while another might perform a different action (say, fetching today's weather report). In this way you can swap out the different types of controllers transparently.

Alternatively, suppose that the temperature gets above 90 degrees, a change in the model. The controller could instruct the view to pop up an alert telling the user to turn his air conditioning on.

Logic that is not strictly related to the presentation or display of the model's data is the job of the model and not the view. For instance, the act of drawing a pie chart showing the percentages of days with temperatures in different ranges would be the job of the view. But figuring out the actual values of the pie chart's different slices would be the job of the model.

hope that helps,

Ok. I'm learning C# right now and just started in on events and delegates. Is the Model Controller relationship the same as the events delegates relationship or am I way off there?

The best way of implementing MVC in C# would most definitely involve events. The model and the view would expose events that are raised when their state changes. The controller listens to these events and updates the model and view accordingly. This way, only the controller has to know anything about any of the other two types.