N-tier deconstructed
The traditional three-layer and n-tier architectures are widely regarded as a “best practice” by many traditional enterprise developers, especially in the .NET world where they are often viewed as a de-facto standard. Unfortunately, many of the patterns and practices that they entail are far from optimal, invariably resulting in poor performance and unnecessarily complex code that is difficult to maintain.
This series of blog posts examines the fallacies behind them and the problems that they cause, and discusses alternative approaches.
Posts
| Date | Title |
|---|---|
| 25th March 2019 | A must-watch talk for every .NET developer by Udi Dahan |
| 4th March 2019 | A brief history of pointless mappings |
| 17th September 2018 | Just how clean is Uncle Bob’s Clean Architecture? |
| 10th July 2018 | Your Repository is not a Data Access Layer |
| 16th February 2015 | Inseparable concerns |
| 16th October 2014 | Moving a problem from one part of your codebase to another does not eliminate it |
| 9th October 2014 | The Repository Facade |
| 21st August 2014 | Query Objects: a better approach than your BLL/repository |
| 14th August 2014 | If your tests aren’t hitting the database, you might as well not write tests at all |
| 24th July 2014 | Interchangeable data access layers == stealing from your client |
| 16th July 2014 | The Anaemic Business Layer |