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 constraints. The view-model provides only the part of the domain model that is relevant to the current screen the user is seeing thus simplifying the job of the view.

.NET, Administration, Agile .NET, Agile, Architecture, Design, User Interface, WPF

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 http://sourceforge.net/projects/procollee. 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 explicitly states where to start in its name. But unfortunately, the presenter first pattern packs too many responsibilities into the presenter. Therefore, not the best source to get an answer from.

But we have to start somewhere, don’t we?

In my experience, I normally know what has to be visualized in a dialog or window, but I don’t know yet how exactly the data is visualized or where to get it from.

.NET, Administration, Agile .NET, Agile, Architecture, Design, User Interface, WPF

In the last post, I showed you the big picture of my UI design pattern. Before I can start showing you sample code for the different parts, I need to introduce some tools, which are used to glue all the tiny parts together:

• Dependency Injection
• Design By Contract
• Synchronous and Asynchronous Communication
• Test Driven Development

.NET, Administration, Agile .NET, Agile, Architecture, code contracts, event broker, Ninject, Test Driven Development, User Interface

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

.NET, Agile, Architecture .NET, Agile, Architecture, Design, MVVM, User Interface, WPF

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.

Principles of Object Oriented Software Design – SOLID

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.

.NET, Agile, Architecture .NET, Agile, Architecture, Design, User Interface

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.

Why is Agile Software Development different?

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.

.NET, Agile, Architecture .NET, Agile, Architecture, Design, User Interface

In my first post (link) I’ve explained what StyleCop is and how you can start with your own StyleCop rules. We will now dig a little bit deeper into the jungle of StyleCop….

.NET, Software, Sourceanalysis .NET, Source Analysis, TDD, Test Driven Development

Zeit für etwas Werbung

prio.conference zum Thema User Interface am 28. und 29. Oktober 2009 in München

Frei nach dem Motto „Es gibt keine zweite Chance für einen ersten Eindruck“ widmet sich die prio.conference 2009 grundsätzlich dem Aushängeschild jeder Anwendung:

User Interface

Auf der prio.conference 2009 am 28. und 29. Oktober in München erfahren Sie in rund 30 Sessions worauf bei der technischen Architektur und dem Design der Oberfläche zu achten ist. Lernen Sie, welche Technologien sich für welchen Einsatzzweck anbieten. Muss es beispielsweise unbedingt ASP.NET sein, wenn ein Programm über das Web bedient wird, oder kann auch eine WPF-Anwendung die Bedienung vereinfachen?

Holen Sie sich auf der prio.conference 2009 Expertenwissen aus erster Hand, damit Ihre Software künftig noch besser bedienbar ist. Denn nicht vergessen: Sie schreiben Programme in den meisten Fällen für Menschen. Und die sollten mit Ihrer Software auch umgehen können.

Alle weiteren Informationen wie das Programm, Referenten, Anreise und vieles mehr erhalten Sie unter http://www.prioconference.de.

.NET, Announcement .NET, Conference, Prio, UI, User Interface

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.

.NET, Architecture .NET, Architecture, Design, Passive View Command, Patterns, Unit Test, unit testing

NMock2 is a library for assisting test driven development of .NET code by providing a dynamic mock object creation framework.

In my last post on NMock2, I introduced the new Stub feature of NMock2 and its basic usage. In the second part, we are going to have a look at the advanced possibilities of the Stub mock style:

• Define Mock Style Of Nested Mocks
• Define Default Values

.NET, Software, Testing, Uncategorized .NET, Mocking, mocking framework, mocks, NMock2