Evergreen on this blog is the Howto: 3-Tier / 3-Layers architecture. But in fact I had some doubts if this usual practice is the best way. Is a three layer architecture with an own DAL always recommendable?
A few days ago I’ve read an interesting blog post which goes the same direction: Keep your code simple!
From Spaghetti-Code to Lasagne-Code
Every developer knows that it’s not necessary to produce a code with 100000 lines for only one function. But it’s possible to reach another extreme: a Lasagne Code. You have Countless layers of code only to make the object move from one layer to the next.
KISS & YAGNI
Before you create an 3-layer architecture without any reason you should ask you one question: Why do I need this?
Why Repository-, Business and Presentation-Layer? Of course it makes sense if you have two Frontends (WebApp and Fat-Client) – but you don’t need it most of the time (YAGNI). The more layers the slower the development process runs. Define another surface here and add a new property there and implement it and only because you want one more field to be shown on the website.
Mh… so how to solve this problem?
I’m pragmatic now and I feel no pain to make the data retrieval directly on the controller (in the sense of ASP.NET MVC). Not until I need the retrieval somewhere else I start thinking about creating a several “Query” class.
I recommend you to do the same with writing processes – do not create a “Command” class before you really need to.
Intent of this: Copy/Paste should be avoided anyway – double the business logic is the wrong way.
And what’s about Unit-Tests?
That’s the point. Without an interface and all this stuff it’s hard to mock. But at least I’m not sure about the real value of Unit-Tests. Countless tests going against Mocks to test at least 5 lines of code.
Integrationtests testing the whole application are at least more significant. These are possible with a SQLLiteDb or you use the usual (but slow) file base and so on.
This should be practicable in a little project without many addictions. How bigger the Backendsystems you need to think about how to test it at the end.
“Poor-Man’s CQRS”
CQRS is a nice concept to divide Queries and Commands (and a lot more).
Daniel Lang (author of the Blogpost “Keep your code simple!”) choose the phrase “Poor-Man’s CQRS” - I like it 
What counts in the end…
At the end of the day the software should work. It should attain his goal and it’s not useful to work “by the book” – it depends…
TL;DR
Before you start building numerous layers and put many Mocks and Unit-Tests in it you should ask yourself: Is this really necessary? What’s the aim? But remember to avoid Copy/Paste and age things after the “CQRS” Principe – Queries for reading things and Commands for actions.