We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Full quote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.Knuth: " Premature optimization is the root of all evil".Many Data Oriented Programming proponents advocate performance over design religion.Some of global use, some workaround for C++ deficiencies.Distrusted by some software developers due to blind (mis)use.Many follow-on (especially domain-specific) patterns.Popularized in 1995 book by the "Gang of Four", Gamma, Helm, Johnson, &Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software".If the dependency is testable and you simply don’t want to directly couple to it, then that might make sense, or it might not! Source Codeĭeveloper-level members of my CodeOpinion YouTube channel get access to the full source for any working demo application that I post on my blog or YouTube. If you’re abstracting a dependency so you can make it more testable, then great. Be aware of when you’re adding indirection and if it actually adding value. Indirection is something we’re constantly creating but it has a cost. Why? Check out my video on Should you use the Repository Pattern? With CQRS, Yes and No! 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. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |