#Level of indirection full#
#Level of indirection code#

Personally, I’d rather not use a repository in this situation. The repository is returning line items and for each line item the associated product. Its purpose is to add the Where() so it’s only fetching the orders for a specific user and to eagerly load the OrderItems and then the ItemOrdered which is the actual product. To get all the Orders out of the Repository, it was taking a Specification. Does it really need to use a repository? what effect does using the repository have? To illustrate this, look back at the Handler that was using the repository. This occurs often when you’re abstracting a 3rd party dependency. Not necessarily from a memory allocation or CPU perspective, although that’s possible, more because when you’re creating indirection through abstractions, you’re often times making your abstraction generic or a limited surface of what we’re abstracting. The second cost is performance because of limited functionality.

#Level of indirection code#

My point is keeping indirection to a level where you have the ability to fully understand the entire request and how it pertains to the application code you’re writing. Meaning you simply don’t have to concern yourself with them. On the flip side, there can be the benefit of not having to worry about certain layers.

#Level of indirection full#

In the example above, it’s pretty simple however you can imagine the more indirection that exists, the more difficult it will be to understand the full scope. If you need to understand the full life of a request and everything that happens, depending on how many layers the request is passing through can be challenging. The first cost of indirection is cognitive load. Instead of having application logic directly couple to a 3rd party dependency, creating an abstraction of the repository allows you to couple to a type that you own (although I’ll argue later I don’t have to). In the case of the repository, its purpose is to abstract the dependency on Entity Framework Core. Let your application code focus on application logic and let ASP.NET Core handle HTTP. To start with, the usage of MediatR can be benefiting from not coupling your application code with ASP.NET Core. Now I’m not implying you should remove indirection! There are clear benefits.

I’ve left Entity Framework as a layer because ultimately you’d be using some type of data access client to get to the database, regardless if that’s Entity Framework or simply ADO.NET directly. Below is a from the OrderController that has a route to show the signed-in users Orders. I’m going to be showing snippets from the eShopOnWeb reference application.

Indirection can come from a message queue, topics, load balancer, etc. If you’ve ever used the decorator pattern or created a request pipeline (check out my post on Separating Concerns with Pipes & Filters), you’re creating indirection.Īnother way to think about indirection which isn’t directly related to application code is infrastructure. This can often be thought to if you’re creating some type of data abstraction layer, a repository, etc. Adding indirection is a useful way of isolating complexity, allowing re-use, and abstracting dependencies as we can have many different callers use the same abstraction.Ī typical example of indirection is adding an abstraction of data access. It’s not inherently bad and comes with a lot of benefits. As developers, we’re adding indirection all the time without really thinking of it.