In my previous post, I talked about how the CatalogController.Product(id) action was completely ridiculous in the level of abstraction that it used to do its work and promised to show how to do the same work on an actual read model in a much simpler fashion. Here is the code.
There are several things that you might note about this code:
- It is all inline, so it is possible to analyze, optimize and figure out what the hell is going on easily.
- It doesn’t got to the database to load data that it already has.
- The code actually does something meaningful.
- It only do one thing, and it does this elegantly.
This is actually using a read model. By, you know, reading from it, instead of abstracting it.
But there is a problem here, I hear you shout (already reaching for the pitchfork, at least let me finish this post).
Previously, we have hidden the logic of discontinued products and available products behind the following abstraction:
Now we are embedding this inside the query itself, what happens if this logic changes? We would now need to go everywhere we used this logic and update it.
Well, yes. Except that there are two mitigating factors.
- This nice abstraction is never used elsewhere.
- It is easy to create our own abstraction.
Here is an example on how to do this without adding additional layers of abstractions.
Which means that our action method now looks like this:
Simple, easy, performant, maintainable.
And it doesn’t make my head hurt or cause me to stay up until 4 AM feeling like an XKCD item.