CategoryArchitecture

Agile UI Development in .NET: Introduction

A

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...

Why MVVM (Model View View-Model) Is Not Enough

W

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...

Event Broker Performance

E

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 Plain .NET events Event over Event Broker Event over Event Broker with logging extension enabled Event over Event Broker with a matching matcher on the subscriber Event over Event Broker with a...

Passive View Command (PVC) Pattern

P

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.

Top 10 of Software Design Evilness

T

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:

Singletons
Enums (or other c# enumeration equivalents)
Swallow exceptions
God classes
Missing interface segregation
Monster classes
Too configurable, too flexible
Abstraction layers not providing additional abstraction
Try catch for program flow control
Missing logging

Clean Code Developer

C

Yesterday, I found an interesting page (in German) describing some of the most important patterns and practices in software development: Although I’m not a fan of wrist bands (see the linked page to see for yourself), I like the page for its short description of patterns and practices like: Don’t repeat yourself keep it simple stupid single responsibility pattern separation of concerns interface segregation principle dependency injection principle Liskov substitution principle open close...

Recent Posts