In my last few posts, I have gone over the data access strategy used in NSK. I haven’t been impressed. In fact, I am somewhere between horrified, shocked and amused in the same way you feel when you see a clown slipping on a banana peel. Why do I say that? Let us trace a single call from the front end all the way to the back.
The case in point, CatalogController.Product(id) action. This is something that should just display the product on the screen, so it should be fairly simple, right? Here is how it works when drawn as UML:
To simplify things, I decided to skip any method calls on the same objects (there are more than a few).
Let me show you how this looks like in actual code:
Digging deeper, we get:
We will deal with the first method call to CatalogServices now, which looks like:
I’ll skip going deeper, because this is just a layer of needless abstraction on top of Entity Framework and that is quite enough already.
Now let us deal with the second call to CatalogServices, which is actually more interesting:
Note the marked line? This is generating a query. This is interesting, because we have already loaded the product. There is no way of optimizing that, of course, because the architecture doesn’t let you.
Now, you need all of this just to show a single product on the screen. I mean, seriously.
You might have noticed some references to things like Read Model in the code. Which I find highly ironic. Read Models are about making the read side of things simple, not drowning the code in abstraction on top of abstraction on top of abstraction.
In my next post, I’ll show a better way to handle this scenario. A way that is actually simpler and make use an of actual read model and not infinite levels of indirection.