Last Updated: 1-28-2009
WPF & Silverlight Line of Business UI Design Pattern Home Page
This page is a work in progress and will be updated each time a new article is added. My goal is to provide an introduction, several simple examples and progress to a series of WPF LOB scenarios where M-V-VM is used. Scenarios like, dialog box, simple form, master – detail, complex master detail with several embedded ViewModels, etc.
I use the common terms Model-View-ViewModel, M-V-VM and MVVM so that Internet surfers can easily locate this material using those names. I like to think that this material extends past the boundaries of the M-V-VM pattern and provides good guidance for authoring WPF LOB applications. Once this series is complete, I will go back and finish the WPF Business Application Series and use this material as a foundation to build some cool applications for that series.
M-V-VM is a guideline, a pattern that developers can elect to use when authoring WPF applications. I like this pattern because it makes unit testing your application very simple. In fact, John Gossman’s litmus test for M-V-VM is that the application can be run without the UI. I also like this pattern because it is easy to use once the developer understands it.
Most of you that know me, know that I’m not a purest by any stretch of the imagination. I’m much more interested in writing testable, bug free, maintainable over time code than adhering to a text book version of a pattern. As a rule, I would much rather author simple code that works and is maintainable than write complex code that only a few can understand.
When looking at a software solution, it’s best to understand not only the code, but also why the developer wrote the code the way they did.
For the purpose of this series my development context and driving goals are:
- WPF Line of Business
- Silverlight Line of Business
- Software development shop is small with limited resources
- UI and libraries must fully testable
- Application users are domain experts but are not computer power users
- Application is transactional in nature (OLTP)
- Application stores data in a SQL Server Database
- Application can connect to the database across the Internet or connected to a local SQL Server Database
- Application will be deployed in a multi-user environment
- Application must never allow the user to perform an action that will cause loss of data or to persist invalid data
- Application must have clean UI that clearly explains error conditions and corrective action
My Articles
I started in the middle of this list and will be filling in the introduction material soon.
Note: I have reorganized the article listing. I’ve added a new application and the first article for it. The application uses the Ocean Framework and the source for the framework is included in the application. The Ocean Code Generation piece will be coming soon.
I’ve decided to place all the source in one post, this way when I update it I only have to update one location.
- Introduction to M-V-VM
- WPF Apps With The Model-View-ViewModel Design Pattern
- Internationalized Wizard in WPF using M-V-VM
- Exploring a Model-View-ViewModel Application; WPF Password Manager, Cipher Text
- MVVM for WPF Line of Business Applications
- New WPF Line of Business – Demo Application Source (contains Ocean Framework source.)
- New WPF Line of Business – Introduction
- ICommand & RelayCommand
- Input Validation – UI Exceptions & Model Validation Errors
- Logging/Error Reporting/Modal Dialogs
- Validation
- Testing
- …
- Silverlight M-V-VM
- …
References
Hope you have a great day!
Just a grain of sand on the worlds beaches.



November 19, 2009 at 1:00 am |
Dear Karl
Idea would be to store Screen names, control names even commands for similar category in db. Load this info into data, data access classes. Going with M V VM dev model, view model need not be aware of views, would it be appropriate to dynamically load screens? In such case how view model and views classes to be defined?
Pls suggest.
Thanks in advance
ursri
November 19, 2009 at 8:52 am |
ursri,
Anything is possible. You may want to look at MEF for run-time discovery and loading of assemblies.
The question is, “is this necessary?” That usually depends on the application requirements.
This will make the application more complex unless the dynamic loading screens can work in isolation.
But this is possible and doable.
Cheers,
Karl
November 20, 2009 at 6:20 am
Thanks Karl for the immediate reply.
Just got into MEF, yet to study further.
Lets consider First name(txt), last name(txt), status(combo box), address(txt) are the controls in Candidate and Employee screens. Would it be good idea to store scree_name,screen_control,screen/control_displayname, and associated commands for both Candidate & Emplyee in database and call a generic view-BasicInfoView.xaml for both requirements, dynamically assign displayname & commands to controls? Does MEF address in same line?
Regards
ursri
November 20, 2009 at 9:27 am |
ursri,
If you need dynamic forms I would write a dynamic form generator. Take a look at the Silverlight DataForm control. This generates a form at runtime.
Dynamic form generators are not that hard to write. They are typically created using some form of metadata. The richer the metadata, the better the generated code will be.
Example:
Property: FirstName
Tooltip: ….
Max Length: …
How the form gets generated has nothing to do with how it is consumed ih the UI.
Once you get your generator working, WPF is so cool that it makes databinding the generated form to a viewmodel an after thought (very easy to do).
Cheers,
Karl
November 21, 2009 at 4:01 am
Thanks again Karl. Shall work ahead in dyn. form generator.
-ursri
November 21, 2009 at 4:19 am |
[...] MVVM – Karl [...]