When you are developing applications for WPF, Silverlight or WindowsPhone you often use ObservableCollection<T> to bind your data to the user interface. The limitation of ObservableCollection<T> is that it will only allow updates from the dispatcher thread. So if you want to insert data into the observable collection from another thread you need to write boiler plate code to marshal the changes back on the UI thread via the dispatcher. I wrote an observable collection which solves...
Updated: Something went wrong with the code snippets. Now it’s okay.
Today, we”l have a look at nested views in my series on agile UI development in .NET using an extended MVVM pattern (table of contents).
There are two kinds of nested views:
contextually nested views and
hierarchically nested views (master-detail scenarios)
In my series on agile UI development in .NET, we have seen quite a lot so far (table of contents). But up to now, we never made a call to the model (business logic, services and so on). This is the topic of this post: Model Commands.
A Model Command encapsulates a single action hat is execute against the model. This can be a query to request data, an action that modifies data, communication with a completely different part of the system or anything else your application has to do on the model.
Next in my series (table of contents) on agile UI development in .NET is the presenter. The presenter is responsible to drive the UI workflow. This means that the presenter is the control center to react to:
events from the model. For example that data has changed.
events from embedded presenters
calls from parent presenter
calls from UI commands
In this post, we are going to have a look at UI commands. UI commands are responsible for reacting to user input, for example the send button click in the sample I use throughout this series of agile user interface development in .NET series. For other posts in this series look here: table of contents.
We have seen in the last post that the view binds a command to the send button that it gets from the view-model:
Last time we started looking at sample code with the view-model class for the UI to send messages on channels (table of contents). In this post, we continue with the next responsibility, the visualization. The View The view is responsible for visualizing the domain model to the user. We have seen in the last post that the view-model provides a simplified mini-model to the view. That means that the view does not have to care about the domain model as a whole with all its interactions and...
After the posts (table of contents) in which I covered why we need an agile UI design pattern, it’s big picture and the needed tools, I start digging into sample code. I’ll show in each post a small part of the whole picture. If you want to get all at once then you find the source of all samples at . ProCollEE is my playground to experiment with WPF and UI design. Lets start Yes, let’s start. But where? There is one UI design pattern – presenter first (link) – that...
In the last two posts of this series (table of contents) I explained the need for a new UI design pattern: changeability and extensibility.
In this post, I’ll throw a big diagram in your face without much explanation. The reason for this is that I want to give you the big picture before I start digging into details in the following posts of this series. You can always come back here to see where we are.
The Big Picture
Just a quick announcement that I’m going to have a speech at the Prio 2009 in Munich on October 28. or 29. 2009. The main topic of the Prio conference this year is “User Interface”. I’m going to talk about UI development the TDD way and show how to use the Passive-View-Command pattern for better testability, extendibility and changeability. I’m touching a lot of topics in this session: MVVM – Model View ViewModel pattern WPF commands and “normal” command pattern Unity – Inversion of Control...