Chris Donnan : Programming - Brooklyn Style
software, trading, family, fun
Posted .net, c#, programming, spring.net on Wednesday, July 5th, 2006.
I have been working to get some stuff together for a decent 1st release of the Spring .Net Desktop Application Framework - Spring.net DAF. I wanted to chat a bit here about the MVP (model view presenter), commands and actions.
In the past - I have seen some ‘fat controllers’ in .net Winforms apps. People try to ‘do the right thing’ and do an MV(C/P) - and seperate the view stuff from the control flow and the commands or tasks. After going through this many-o-time, I believe I have been able to model out a good set of constructs.
- View - tries to perform Actions via it’s Presenter (user controls for the most part)
- Presenter - has buckets of Commands and a View
- Commands
- Presenter Commands - automates the view and manages ‘non UI related tasks’ including background tasks.
- Background Commands -reusable - async units-of-work
The container
First and foremost - The UI Application Container should inject any needed dependencies into the UI. This includes bulding up the presenter, commands, etc. that a view is expecting.
View
These are your friendly UserControls and forms. In essence, the goal is to keep the Views - dumb. The view should basically have an API so it can be implemented by person A (theoretically) and automated by some presenter yet to be implemented. Here is a simple button click - asking the presenter to handle an action being requested. The view can pass parameters with the Action in a CommandParameter list. These are typed via generics.
Presenter
The Presenter is then free to do whatever it needs to - and then automate the View as needed.
The presenter has it’s commands wired up via spring - like so….
This means that you can add in commands, change the implementation of a command, etc. Often - a ‘generic’ presenter can be used - that just wires commands to a view. These Presenter Commands have access to the Presenter and the View to do whatever they need to do. This means that all UI Operations can be canned up in a command - a single unit of work… nice, testable.
Commands
Here is an admittedly useless command:
This command is just wired to a name via spring. It does what it needs - in this case - just dealing with the view. In this ‘do execution’ method (a template method) - you could do whatever. This PresenterCommand class derives from PresenterCommand - a base class that does the basic PresenterCommand implementation - there is also a BackgroundPresenterCommand that could be derived from - providing more template methods - that would do ‘background work’.
Also note this command is ‘view cognisant’. There are also - in my way of thinking - non-view-cognisant background commands. I have called these ‘units of work’ in the past. These are typically called - in this model - in the PresenterCommands.
Command Parameters
Note the simple use of CommandParameters here too. This is a simple example of just getting the value of an expected parameter passed to this command via The Action’s CommandParameters. The Command/ Command Parameters are loosely modeled off of the ADO Command/ Sql Parameters. My goal was to try to give metaphor that ‘feels normal’ to developers. I think the level of usage that the ADO Commands have provide a good baseline for usage.
This is just a quicky intro to what has been going on. Hopefully I will find the time to getting this stuff out there ASAP.
My best;
Chris
Comment on this post below
You must be logged in to post a comment.
You can leave a response, or trackback from your own site.