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:
The process class. It provides and consumes information/data that is strongly coupled with the functionality it provides
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.
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!
Maybe you already knew this but VMWare now provides a free VMWare server package. It has most stuff that Microsoft VirtualServer has but you don't need Windows 200x and a VirtualServer license to just host some XP / Ubuntu images.
A nice thing too is that both Microsoft Virtual PC and Virtual Server don't run on Microsoft XP Home Edition and VMWare server runs just damn fine ;-) I need this at home because my new pc doesn't have installation cd's but only a recovery partition without installables.
Currently running Ubuntu and Windows 2003 and both run and perform quite well.