Ramon Smits

Tell me your secrets and i'll tell you mine

Recent Posts

Tags

Community

Email Notifications

Patterns & Practices / Guidelines

EntLib

Nant

Blogs that I monitor

Archives

Would this comply with the model view controller (MVC) pattern?

I'm busy with a nice personal cool tool. I wanted to experiment a bit with hashing and alternate data streams and will publish the tool soon on my blog.

I am having refactoring issues with my current code. I always try to seperate ui logic from functional logic so I treated this project the same. The application really has a small and simple gui. It has a main screen where you can change some settings, an action button that triggers a (long running) task and a result pane. The long running task is running in a modal dialog that the user can cancel if it wants to. Both dialogs (the mainform and the taskform) communicate with a a process class that does the actual smart stuff.

I am having the following lifetime in my application

1 Application starts
2 Main form is created
3 Main form creates process class
4 User changes settings in main form
5 User triggers action on main form. The form first calls Process::UpdateSettings() and then Process::StartTask()
6 Process::StartTask() starts a task on a seperate thread and exists
7 Main form creates a TaskDialog.
8 TaskDialog polls Process to update the screen with information about the running task
9 When the task is finished it triggers the mainform through a delegate
10 Model task dialog is closed
11 Main form shows the results from Process in the result view
12 Main form closes and application quits


Would this application comply with the model view controller (MVC) pattern? When looking at this small application I think I have the following design:

Model :
The process class. It provides and consumes information/data that is strongly coupled with the functionality it provides

View:
The mainform and taskform dialogs. Both have simple logic and timers events and get called by the model to update their controls with new information.

Controller:
The controllers are the control's on the forms that triggers events that the views uses to update it's content. This could be user that interacts with the application or timer events.

So this would give the following translation:
User performs input, this triggers events on the views (forms), events get handled by the view and delegates functional logic to the model (proces class), the view updates its content by polling the model, the model calls the view (through a delegate) when results can be processed for presentation, the view retrieves the data from the model and fills its controls. All parts are happy and the user quits the application.

Again, does this application comply with the mvc pattern? If it is not then why not? I obviously left out the controller bits for one reason and that is that the controller could only consist of a collection of eventhandlers that get called by the actual event handlers of the forms. I really don't like such a useless layer and really don't see a reason for it to be there. Should the controller class implement the eventhandlers? If controls on the forms triggers events that the controller will be called directly?

By the way... have a nice weekend!
Posted: Fri, Feb 24 2006 11:14 PM by Ramon Smits | with 5 comment(s)

Comments

Harry Maes said:

Model = basically Business data. This is very generally thought.

Controller = your process class and mediator between views. Essentialy your windows forms are mediators (controllers) too. They handle the events from the different controls which are placed on the form (or usercontrol).

View = Any UI element (form, user control etc.)

Check out the patterns: Mediator (controller) and Observer (for pub/sub).
You can also check out the UIP block from Microsoft.

Grtz, Harry
# February 27, 2006 12:44 AM

Marc Jacobi said:

I'm not quite getting all the details here but I think you could say that the main form and the task form should be views and not in your case also controllers. Also take a look at the Model View Presenter pattern which is similar to MVC but more usable in my view for Microsoft (web)Forms.

In MVP the view and the model are completely agnostic of each other and it is the presenter (controller) that knows how to tie them together. The Presenter registers on view event to handle user interaction and drives both the view and the model.

So in you example I would let the Application create the process object and hand it to the main form presenter. The MainFormPresenter knows about the process object and the form itself. This MainFormPresenter is the one that calls StartTasks() on the process object and perhaps initializes the TaskForm and the TaskFormPresenter. The TaskFormPresenter knows how to keep an eye on the status of the process object concerning tasks and call the TaskForm to display the result when they become available.

Programming Presenters might look like overhead but I've been trying this appraoch for some time now and it works great. Your views will become very thin only containing UI code and perhaps some databinding helpers and your model can be optimized for business. The Presenter is the glue (controller) between the two.

http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
# February 27, 2006 4:02 AM

Ramon Smits said:

In your definition the presenter is tightly coupled to the view. I don't really see the benefits for this option to extract the eventhandling from the view into a seperate class.

I don't think the MVP pattern suits asp.net webforms very well. User interaction is very different between a simple web application, ajax or rich windows form. This is where MVC wins bigtime. The View/Controller are tightly coupled. The MVP tries to seperate these.

The problem with the MVP pattern is that the view can't communicate with the model. If you would define that eventhandler logic on a windowform are part of the presenter then this isn't really a problem. The example of martin fowler it just too easy. The presenter works with an IAlbumView. This interface describes which data and events should be on the form. This makes it less tightly coupled but I really don't see why I should develop this way. You could say you could just throw away your VisualStudio designer because you'll never use it.
The view implements the IAlbumView so if you would like to change the behaviour of your application then you have to change atleast 3 (!!) classes. So I am really not in favour for the MVP pattern. You try to make if loosely coupled while they are not. So changing the design will be a kick in the ***.

I'm also a bit worried about those presenters and their lifetime. Having a MainForm(Presenter) and TaskForm(Presenter) isn't really logical because the forms are tightly coupled. The user cannot interact with the mainform while the TaskForm is visible. I think it would then be more logical to have a MainForm, TaskForm and one presenter.

The problem is that the application must stay responsive while the long task is running. So it should keep listening to events and handle them. I haven't found a good example that focusses on this problem where you have multiple threads/forms.

Well... atleast both the MVP and MVC patterns stuff the real logic into the model :) and that is what is most important.
# February 28, 2006 4:24 AM

Erwyn van der Meer said:

Check out John Gossman's blog: http://blogs.msdn.com/johngossman/default.aspx

He has several related posts on MVC, ModelViewPresenter and another variant that is used in Windows Presentation Foundation: Model/View/ViewModel.
# February 28, 2006 5:39 AM

Ramon Smits said:

Reading a couple of posts at John's his blog I came accross the following post:
http://blogs.msdn.com/johngossman/archive/2005/10/11/479632.aspx

He writes:
"All of these variations exist because while everybody agrees Model and View separation is love, Controller was always the odd one in the trio, and as UI technologies have advanced it has been subsumed more and more into the View or the framework itself."

Which indeed is quite right. When you take into account that the view part is something those nice IDE's should help us with then that is what should change. The IDE should seperate certain view aspects. VS2005 does a pretty good job by using partial classes but it doesn't fit an existing pattern.
# March 1, 2006 3:01 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 6 and 6 and type the answer here: