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
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.
.NET, Architecture, Testing
Model-View-Controller, Model-View-Presenter, Passive View, Passive View Command, Patterns, PVC, Test Driven Development, Testability, Unit Test
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
Architecture, Software
Architecture, Design, Patterns, principles
Yesterday, I found an interesting page (in German) describing some of the most important patterns and practices in software development: http://www.clean-code-developer.de/
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 principle
- law of Demeter
- principle of least astonishment
- you ain’t gonna need it
- use a version control system
- issue tracking
- continuous integration
- automated tests
- mocking
- code coverage
- test first
- reviews
- and some more
Architecture, Software
Architecture, Clean Code, Design, Development, Patterns, Practices
