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:
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:
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.
In the first post in this series (table of contents) I explained why agile software development influences the choice of the UI design pattern. For short, changeability and extensibility are must have characteristics.
In this post, I’ll show you the corner stones of a UI design pattern that fulfills these needs.
One of the best known set of principles to achieve my goal of a UI design pattern that is changeable and extensible is SOLID by Robert C. Martin (link).
If you don’t already know those principles then please follow the above link and read it before continuing here.
The principle I’m most interestes at the moment is the S in SOLID, the Single responsibility principle:
A class should have one, and only one, reason to change.
There are a lot of patterns available for UI architecture: Model-View-Presenter (MVP), Model-View-Controller (MVC), Passive View, Model View View-Model (MVVM) and some more.
However, none does really fit my needs in an agile project.
In this series, I’ll show you first why they don’t work for me and then I’ll try to evolve a pattern that matches the special needs in agile software development.
In agile development, we start little and add small parts to evolve a complete application. This approach allows us to deliver every sprint (= iteration in Scrum terminology; 2 weeks in our case) a working software and to get early feedback from our customer.
When we start a project, we don’t have a complete requirement specification (nor do we want one). The requirements (or user stories in Scrum) evolve together with the software: appetite comes with eating. The requirements get clearer and more precise as we learn more about what the software has to do and how we can implement them providing best user experience.
The Model View View-Model pattern gained a lot of momentum lately. It allows to reduce the code in the code behind class of a form or user control to a minimum. Therefore, unit testability is improved dramatically compared to other view patterns like MVC/MVP.
However, when I design software, I follow (amongst others) the principles of SOLID (link).
The first principle in SOLID is the Single Responsibility Prinicple (SRP) that states that “A class should have one, and only one, reason to change.” (link)
And here start my concerns about MVVM.
I wondered about the performance of my event broker (CodeProject article) implementation in bbv.Common.
Event Broker: a notification component for synchronous and asynchronous, loosely coupled event handling.
Therefore, I implemented a quick performance test application that prints out the timings for
As well as how the number of subscribers on a single event influences timings.
When I’m coaching teams in Test Driven Development (TDD), I’m often asked how to deal with the User Interface (UI). The problem is that the unit test frameworks are weak in testing Forms, Controls, Buttons, Grids, and so on. Weak because they do not support it at all or the tests become very fragile (e.g. renaming a Label causes the test to fail).
We address this problem with the Passive View Command pattern, PVC for short.
These are my personal top ten of software design evilness. That means ten designs that make your software either complex, untestable, monolithic, unchangeable or hard to understand: