Extremely FAST Caching Repository With Decorator Pattern in ASP.NET Core

[@MilanJovanovicTech]

Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt

[@filipeencarnacao2840]

I already knew this pattern, because of Steve Ardalis, and let me tell you, i used this in a software project, from the company i work at, and it didn't cost almost any time, simply fantastic

[@MilanJovanovicTech]

Excellent pattern indeed. And you can keep reusing it all over the place.

[@Jbobonline]

Thanks Milan, Please keep in mind that using a DISTRIBUTED cache is required in order for your service to be scalable. Otherwise, different instances of the same service will not be aware of each other’s in memory cache. Great video!

[@MilanJovanovicTech]

Of course, if you have multiple services running then you need a distributed cache.

[@musacj]

Milan, I like the way your videos have detail and they're not too long either. The simplicity of your explanations have made me want to implement most of things you explain on your videos. Your presentations aren't too fast and not too slow, so it makes it easy to understand. Thank you for your time

[@MilanJovanovicTech]

Thank you for watching them! 😊

[@PelFox]

I use the same pattern, its great. One thing I like to add is to have any Update/Delete method to clear (or update) the cache.

[@MilanJovanovicTech]

Smart!

[@kharade123]

this is what I was looking for

[@DanGahagan]

I was looking for that as well. Would be a nice topic for a future video

[@nickolaki]

How would you implement that ? Would love to know

[@michaelswells]

@@nickolaki We usually do a try get, if it exists, we remove from cache and then add it back in with the updated values. We do not do physical deletes. We mark the record as deleted.

[@markovuckovic9430]

This is amazing... Even though I use different tech stack in my projects, the concept of implementing cache with decorator pattern is something that I'm willing to try out as soon as there's an opportunity for that...

[@MilanJovanovicTech]

There are many other use cases for Decorators, such as: logging, validation, resource-based authorization...

[@radeksendecki9922]

Great work. As always clearly presented in the simplest form, but covering the essence of the subject.

[@MilanJovanovicTech]

Thanks a lot, Radek 😁

[@tedchirvasiu]

That Scrutor implementation seems more flexible which is really cool.

[@MilanJovanovicTech]

I really like it also, easy to write when you have a lot of dependencies

[@tedchirvasiu]

@@MilanJovanovicTech Thank you for showing it

[@ALOKSHARMAMD]

i have used this implementation in conjunction with Faster hybrid cache, and works fantastic for my system. we implemented this a few years ago and never had to look back.

[@MilanJovanovicTech]

You're using HybridCache from preview?

[@ALOKSHARMAMD]

@@MilanJovanovicTech no not that, the one called Microsoft.Faster, it have hybrid caching in sense that it provides both in-memory and persistent disk cache to go beyond memory cap[acity. i have built my layer on top of this library. btw i tried commenting with git link for library but my comment was not posted.

[@milicabozic9897]

Awesome video, I really like the way you explain things 😊

[@MilanJovanovicTech]

Thank you, Milica. I'm glad you found the video useful 😁

[@samuelterrazas3191]

I always watch your videos. They've really helped me a lot in growing professionally in my job. Honestly, I would pay to watch your videos with subtitles correctly translated into Spanish instead of the automatic KZbin ones that often don't work well or translate incorrectly.

[@MilanJovanovicTech]

That one's gonna be tricky 😅

[@kydlnw2023]

I was really thinking about doing something like this but had no idea how to do it(1st year on software dev uni so don't know quite a lot). Thanks for the video.

[@MilanJovanovicTech]

Pretty cool, I'm glad you ran into this video then 😁

[@andersjuul8310]

I thought I'd seen you make a video on this -- and just what I needed. Brilliant, to the point as always. Thanks!

[@MilanJovanovicTech]

Glad it was helpful!

[@adiazwise]

Thanks, Milan , excellent implementation of the decorator pattern.

[@MilanJovanovicTech]

Awesome, glad you found it useful 😁

[@camilotorresc.2046]

Fantastic video, well explained. I have used Scrutor and the way that works is so good because under the hood it uses the built-in ASP .NET Core DI container. I guess that caching behavior can also be done using the new Output caching middleware built-in .NET 7. Great video!

[@MilanJovanovicTech]

It's an entirely different type of caching, so we should be careful. I think it's more appropriate for caching HTML output.

[@sergiom.954]

Very clean design for caching queries on repositories. I already have in mind a few queries of my project to implement the pattern this way. Thanks Milan!

[@MilanJovanovicTech]

Awesome Sergio, glad you can apply this to your project 😁

[@colinwiseman]

Although I know I'll never change my repo or my cache layer, I really get old grumpy and I would merge the cache code into the repo. but that decorator DI stuff just makes it clean! This old dog may have learned a new trick 👍

[@colinwiseman]

But question : why add Scrutor when you had it working already? Adding third party for no extra benefit doesn't seem smart.

[@MilanJovanovicTech]

Just wanted to show multiple options, by introducing Scrutor. In general, I would use Scrutor by default since it's more feature rich.

[@colinwiseman]

@@MilanJovanovicTech fair, if you use many of the features. My fear for many a bit of software out there is over engineering, especially if it someone building a website for their local coffee shop 🤣 I've seen too many examples of Financial Institution grade coding running on websites that make them so complicated that the next Dev along can't fix it 🤣 that's why I always question additions for the sake of additions. But that Decorator pattern with DI... That's a worthy addition.

[@ahmadsabbagh1554]

Great work. Keep going 😍🥰

[@MilanJovanovicTech]

Thank you so much! 😊

[@EmptyGlass99]

Very clean and useful presentation.

[@MilanJovanovicTech]

Thanks, I'm glad you liked it 😁

[@miodragsimunovic5851]

Neat and tidy ! It's great you have shown few ways for service registration.

[@MilanJovanovicTech]

Which did you like the most?

[@miodragsimunovic5851]

@@MilanJovanovicTech Hi Milan. The second one is the most detailed and lets you customize it a bit more. The Scrutor is fine, but leads you to dependency on 3rd party library fortunately one which can go along with other DI containers. Great job !

[@daedwill]

Very clear explanation, thank you!

[@MilanJovanovicTech]

Awesome, I'm glad you liked it! 💯

[@yunietpiloto4425]

Really nice stuff man, well explained, well presented...quality content, keep it up!

[@MilanJovanovicTech]

Thank you so much! 😁

[@krzysztofhandzlik9273]

Great video ! However it would be worth mentioning, that we should keep in mind some cache invalidation strategy. Thanks for Your work :)

[@MilanJovanovicTech]

Definitely, I kind of failed to cover that aspect properly. I'll make it right in a future video

[@beirinhaaa]

Very Nice explanation!!!! TKS for show many ways to do that!

[@MilanJovanovicTech]

You are welcome!

[@lucek15951]

Found your channel a few days ago. You are doing a magnificent job. The implementation details, like the options for registering services in DI, are fantastic!

[@MilanJovanovicTech]

Thanks a lot, Kamil! I'm glad you liked it 😁

[@shanemonck783]

Awesome loving your videos! so happy I stumbled upon your page

[@MilanJovanovicTech]

Thanks a lot Shane, I'm glad you're loving the content 😊

[@krccmsitp2884]

Well done, comprehensive and straighforward as always in your videos. Besides, one should consider using ValueTask instead of Task in such cases.

[@MilanJovanovicTech]

Why do you think a ValueTask is a good fit there? 🤔

[@krccmsitp2884]

A ValueTask is more lightweight, with less memory usage since it's a struct, and doesn't create an actual Task when it is already completed when awaited--which is mostly the case in this use case of caching.

[@androidsavior]

Is it a best practice to always a have a repo and a cached version of the that repo or we can integrate the caching inside the one single repo ?

[@MilanJovanovicTech]

You're welcome to just have caching in the repo

[@ugurcan4638]

So helpful video series. Thank you. I want to ask what is the shortcut keys at min 6:43 (navigating to Program.cs).

[@MilanJovanovicTech]

Ctrl + T?

[@ugurcan4638]

Thanks a lot@@MilanJovanovicTech

[@LindenMikus]

I think for unit testing the scutor approach is the nicest to work with because you are dealing with an interface instead of direct class

[@MilanJovanovicTech]

Agreed, plays very nice with unit testing

[@pedroferreira9234]

You can still use the interface with addScoped I think you just need to use the provider services.AddScoped(); services.AddScoped(provider => new ServiceCache(provider.GetRequiredService()) ); where the Service : IService

[@eddypartey1075]

Milan, I'm not that experienced but why don't you use async/await in CachedMemberRepository?

[@MilanJovanovicTech]

Returning a Task is enough

[@rezameshksar503]

Great presentation as always. What is the best practice and approach to conditionally use cached data? For example, can the API look at cache header in the request, and decide which repository to use? How does the DI configuration work in this case? Maybe a repository factory class?

[@MilanJovanovicTech]

You can inject the HttpContext which should have the headers present perhaps, and check if you should use cache or not

[@codewithkashif]

Great video, simple and pragmatic too! My only question is in decorator patten conventionally existing class will remain as is and new wrapper class behaves as decorator. this means in this case CachedMemberRepository class should act like decorator. kindly let me know your thoughts

[@MilanJovanovicTech]

Yes

[@codewithkashif]

@@MilanJovanovicTech so in your example you have used it vice versa so is this decorator pattern too?

[@volodymyrliashenko1024]

Thanks Milan! I need to try using Scrutor library. But do you know how to create decorator dynamic/on fly? I was able successfully do that with Castle library and IInterceptor interface, but having issues during the debug. So, I'm thinking the better solution would be having the Source Generator which would create a decorator for me. Did you try to do something like that?

[@MilanJovanovicTech]

I didn't need to do something like this before

[@taner-saydam]

An ingenious way, thanks🤩🤩

[@MilanJovanovicTech]

Glad you like it!

[@taner-saydam]

​@@MilanJovanovicTech I live you all videos. Thanks a lot. Really ☺

[@NAEL4SLR]

Awesome contents! Thanks for sharing

[@MilanJovanovicTech]

Thanks for watching!

[@vAmp1que]

Milan, appreciate for your time! We are gonna set the cached entry every time when we decided to update the entity, isn't it? So how to do it better? Is it better rather than using only EF or it depends on situation. For instance, in project where we changing entities rare it may be huge performance upgrade, but in the opposite situation we could get some performance degradation imho. What's your opinion at this point? Thx.

[@MilanJovanovicTech]

I think that updating the cache when you update the Entity is a viable option. We can usually live with a short stale cache.

[@vAmp1que]

@@MilanJovanovicTech thx man. And thx KZbin algorithm for recommendation. Really enjoy your content. Hope your channel will growth up even faster than 233x;)

[@MilanJovanovicTech]

@@vAmp1que I hope so to 🍀

[@monsieurnet]

I wonder if it's really usefull to use Decorator pattern on a repository for this purpose. Because you have to create a new class for all the repositories you want to cache the data. Creating a generic repository with cache feature is maybe easier to handle on long time perspective even it's not a SOLID principle ? I would like to know your advise.

[@MilanJovanovicTech]

Too much generic will constrain your design, so tread lightly

[@monsieurnet]

@@MilanJovanovicTech Thank you for your answer. I will take it in mind for my next development

[@ezecel9]

Thanks! If instead of an id I want to filter by many conditions (for example, Page, PageSize, MemberName, memberDate, etc), do I have to concatenate them in the key? Or maybe make a hash with the sql generated by EF? Which is the best approach? Thanks!

[@MilanJovanovicTech]

Yes, you need to include anything that can change in the cache-key

[@abdelrahmanmahmoud2285]

Awesome video , keep going

[@MilanJovanovicTech]

Thank you!

[@hmsiegel79]

Hi Milan, I noticed something while going through the video. I was having trouble getting the caching to work and was getting a circular reference error when starting the application. I then noticed that you added "build.Services.AddMemoryCache();" after running the application the first or second time. Just an FYI if others have the same issue.

[@MilanJovanovicTech]

Thanks for pointing that out!

[@xantari79]

I see you using a lot of keyboard shortcuts to auto complete things. Perhaps it would be a good idea to show those in a tips and tricks video?

[@MilanJovanovicTech]

Maybe, but it's just a few basic shortcuts

[@TheAproeX]

What is the best time for the cache to expire? How should we calculate this, what should the decision be based on? I know that cache invalidation is a complex topic, but perhaps there is a simple way to determine this?

[@MilanJovanovicTech]

It depends on the load on your application, really. And how long the value can be valid in the cache. The longer you can cache, the better. I usually use 5-10min for values that can change from time to time.

[@TheAproeX]

@@MilanJovanovicTech Thanks for the answer. Btw. what keyboard do you use?

[@MilanJovanovicTech]

@@TheAproeX Nothing fancy: Logitech K120 Gets the job done 😁

[@pazzuto]

Since the decorator class adds additional functionality to the repository, I normally add code to clear (invalidate) the cache when one of the other methods are called (UD) in the decorator class; that way I don't have to guess how long to cache.

[@sameerpanicker7452]

Milan, if we have multiple service classes or repos and we need to implement caching on all of them, should we create separate decorator classes for every service class ? Is that the correct way of doing it ? Could you please suggest any good practice?

[@MilanJovanovicTech]

That's what you'd end up with... Perhaps there's some clever way to implement this with attributes.

[@sameerpanicker7452]

Thank you Milan for the suggestion. I will have a look.

[@thegaribovv]

I have some methods which accept Expression as argument, How can I generate cache key for this expression? Generally should we cache expression based methods result?

[@MilanJovanovicTech]

It would be smart to pass in the cache key as an additional argument

[@thegaribovv]

@@MilanJovanovicTech Then it will broke the repository pattern

[@DavidGagne]

This is very interesting, thank you for your videos! I would assume that MemberRepository is for read purpose only? Because I use the repository pattern for writes, and I don't think caching entity would work.

[@MilanJovanovicTech]

Why wouldn't it work? Because EF wouldn't track it? We can fix that easily with Attach.

[@DavidGagne]

@@MilanJovanovicTech Ok yes it should work with Attach! Thanks

[@salmanzafar-jr1iu]

Don't you think it's a proxy pattern I just got confused :) can you clarify as per my understanding The proxy pattern adds a layer of indirection to the object that it is wrapping. The client interacts with the proxy, which in turn delegates requests to the wrapped object. This can be used to add additional functionality to the wrapped object, such as caching, lazy loading, or security checks. The decorator pattern, on the other hand, adds new behavior to an object by wrapping it with a decorator object that contains the new behavior. The decorator object implements the same interface as the wrapped object, and forwards requests to the wrapped object. This allows you to add new behavior to an object without changing its implementation.

[@MilanJovanovicTech]

Yeah, it does seem that this is the "Proxy" pattern after much comments on this video.

[@davidwilliss5555]

Nice, but in your update method on the decorator class, you should modify the Update function to at least invalidate the cached instance if it's already in the cache or the next get will get the old value instead of the new one.

[@MilanJovanovicTech]

Good suggestion

[@loam]

I guess, when updating the entry (which is Member in this case), cache also should be updated. Is it so?

[@MilanJovanovicTech]

Indeed, that should be the case. Or rather - we can just clear the cache, and let the next query fill it.

[@loam]

@@MilanJovanovicTech Thanks for the reply 🙏👌

[@GeoffSeeley]

This assumes your API is the only source of change in the database. If that is not the case, you risk stale data in the memory cache before it expires so that is something to be aware of.

[@MilanJovanovicTech]

Of course, this is just one piece of the puzzle.

[@agustinmolina5170]

i give you like from start because i see you like Warcraft!!

[@MilanJovanovicTech]

Haha, used to play a lot back in the day 😁

[@feitoza.system]

I like to read, but it's kinda too theoretical. You make this feel so practical and real in the daily development, I'm following you to learn everything I can about good practices and performative code

[@MilanJovanovicTech]

Awesome, I'm so happy you found this video helpfuln

[@markus27183]

caching is about as practical as you get

[@balajisairamnarasimhan]

Mostly recommended cache is distributed cache like redis , mongodb etc rather than mem cache

[@balajisairamnarasimhan]

If the use case is simple , then it makes sense to have this memcache 😊

[@MilanJovanovicTech]

You won't need it in a non-distributed system

[@shabtaiben-david8173]

what about the case I need to refresh specific id data, i.e. ignore cached instance?

[@MilanJovanovicTech]

kzbin.info/www/bejne/j5Wok3draMhreNU

[@shabtaiben-david8173]

@@MilanJovanovicTech Thank you, actually I mean how to integrate it into GetOrCreate mechanism (not rabbitMQ in my case). I just thought about passing 'bool suppressCache' argument to the CRUD operations...

[@balsastevovic9225]

What if you add a new member, and then after you call the GetAll in the CachceRepository? Its not gonna have the newly added member?

[@MilanJovanovicTech]

Invalidate the cache after adding a member

[@balsastevovic9225]

@@MilanJovanovicTech Thank you!

[@andersjuul8310]

Say, if organized in a clean architecture, where would you think the decorated class should be? To me it's kinda a technical concern not appropriate for Domain. Where then? :)

[@MilanJovanovicTech]

A decorator of what? If it's a decorator solving technical concerns, then it's probably more appropriate to place it in Infrastructure

[@andersjuul8310]

In my case it is decorating a Domain Service -- but the caching itself seems like a technical concern. Infrastructure-for-caching does seem appropriate. Thanks again!

[@vincenthamelin6115]

Would it be possible to update the video (or make a different one) where you show how you would implement invalidating the cache when inserting, updating and deleting. Thanks

[@MilanJovanovicTech]

kzbin.info/www/bejne/j5Wok3draMhreNU

[@donatolucente1209]

What abount entry invalidation? how do you implement it with this approach?

[@MilanJovanovicTech]

Simplest would be straight in the CachedMemberRepository. Decorate the other methods the make changes, mainly Update, and invalidate the cache.

[@donatolucente1209]

@@MilanJovanovicTech Thanks!

[@vivekkaushik9508]

Brilliant.

[@MilanJovanovicTech]

Thank you very much! 😁

[@amitsinghrawat4760]

Hi Milan, Requesting video on Concurrency token and Handling Concurrency Conflicts by using EF core.

[@MilanJovanovicTech]

All right Amit, I added it to my production list 😁

[@ahmedanwer1767]

Awesome

[@MilanJovanovicTech]

Thanks!

[@sandorvarga7437]

Success.

[@MilanJovanovicTech]

💯

[@chriscardoz]

Castle proxy ? Any drawbacks ?

[@MilanJovanovicTech]

Haven't used it, so I wouldn't know

[@UsmanKhalidTV]

Very clean code. Can you please also upload your code to github repository.

[@MilanJovanovicTech]

I share the code with my Patreon supporters. But there are some examples available on my GitHu that you can look at :)

[@jamesattwood6809]

Great video thank you. I am looking at making a GenericRepository (Using Generics) to handle basic CRUD functionality with EF Core to handle various entity types via T. I would like to also have a GenericCaching repository as well based on this repository. I have existing service classes doing this work currently that I am now able to offload to the main generics repo by inheriting the GenericRepository base class and passing in the entity type. Since my endpoints are injecting the service class for a given entity type (because each service class also has additional methods) I am struggling to figure out the chain of inheritance here and how I can make a call to the service class and have it route correctly between cached and non-cached . I suspect it would be a different design pattern... Currently I am using your DI mapping technique to map between the cached and non-cached service classes. Each of these classes inherits from the cahced and non-cached base classes. This is working, however I am not sure if this is best practice/ or the most elegant solution. Any thoughts appreciated!

[@MilanJovanovicTech]

With the Decorator pattern as I showed it here, you can't really control which method you are calling (cached/non-cached). You would need to think of something else. Or create two separate services perhaps? Inject both, and decide which to call?

[@jamesattwood6809]

@@MilanJovanovicTech I Need to think this one through clearly. Appreciate your thoughts on this!

[@majormartintibor]

Milan pls consider to make a discord server. Would be awesome.

[@MilanJovanovicTech]

Good idea Martin. I'm definitely going to do it at some point.

[@ryanalafountain]

How do you add the cached member to change tracking?

[@MilanJovanovicTech]

dbContext.Attach(member)

[@ryanalafountain]

@@MilanJovanovicTech so I would just inject the context into the decorator as well? Would it make more sense to implement the cache in the repository instead of decorating in that case then?

[@MilanJovanovicTech]

@@ryanalafountain I think you can handle attaching in the decorator also, along with the caching. So you just inject the context into the decorator, resolve from cache, and attach.

[@kenjiobara]

how to generate construct using the new sugar syntax?

[@MilanJovanovicTech]

What did you mean to say here?

[@jeetsingh4588]

what if your generic repository have predicate/func type parameter, how you will make a cache key unique in that case?

[@MilanJovanovicTech]

Pass the cache key as another argument

Decorator pattern is really nice, but there is a lot of boilerplate. It would be nice to see a SourceGenerator for this pattern.

[@MilanJovanovicTech]

How will you control cache time, cache eviction, keys?

​@@MilanJovanovicTech Might be done with Attributes etc., however. It would probably not be the cleanest, as .Net does not support TimeSpan etc. on Attributes ("00:00:00.000" strings instead?). Writing the class partially is also an option, but not easy to say. Next time I use this pattern (maybe 3 years since last time), I would definitely look into creating my own generator, if it does not exist then. And well, If I need to create a short generator, then I could just predefine some of the rules in the generator myself also I guess. Have to say, have used both generated (IL.Emit) proxies and Fody for similar issues before. But that seems like overkill at this time.

[@InshuMussu]

i am a fan of you ❤

[@MilanJovanovicTech]

Thank you! :)

[@andresbeltran5779]

Excellent

[@MilanJovanovicTech]

Thanks!

[@nasih6474]

Can i get this source code if i join the patreon?

[@MilanJovanovicTech]

Yes, that's the whole point :)

[@guillermovalenzuela9509]

Talking about decorator pattern, why you dont use a base decorator class , every concrete decorator must implements base decorator instead the concrete component

[@MilanJovanovicTech]

What would be the benefit of that approach?

[@guillermovalenzuela9509]

@@MilanJovanovicTech more than a benefit, I want to understand because the classical pattern defines four steps : a component, concrete component, a base decorator class and some concretes decorators

[@utubewebbes]

This is not the decorator pattern. It's the proxy pattern. A decorator decorates an existing class with new functionality. E.g. you have a Shape class that contains information about its dimensions and you would like to add a Paint method to that class in order to render it on a canvas. You use a decorator to add that completely new functionality. The proxy pattern allows you to replace any reference to a specific type of interface to an instance of the proxy and the proxy will do something with requests before it will proxy the request to the instance being proxied. Proxies are useful for adding logging, adding event triggers, encoding/decoding (SSL offloading) or... caching. You probably will have heard of network proxy servers.... that are most often used for SSL offloading and caching.

[@MilanJovanovicTech]

It's still not as clear to me. And I've read a lot about Decorator vs Proxy after posting the video. By some definitions, this is a Proxy indeed. By others, I can designate it as a Decorator. The line between them is very fuzzy.

[@utubewebbes]

@@MilanJovanovicTech The reason line seems blurry (but it isn't once you know) is that a decorator should also act as a proxy. The existing methods of the class being decorated should also be present on your decorator and for those methods, the decorator acts as a proxy by simple passing the request down to the class it decorates.

[@serb1146]

Both patterns are wrappers. Both based on composition principle. But diff is that proxy manages life cycle of its "proxied" object itself, instead decorators composition controlled by client code. Therefore, in this case, client code decided "game rules". This is more decorator than proxy IMHO. Thank you for video/idea, Milan, keep been so informative!

[@Bennevisie]

Semantics. Big question is: “Does it achieve the desires outcome?”

[@eobardthawne6903]

Thanks for pointing this out. I was thinking the same.

[@empireofhearts]

how would you handle cachetimes being stored in config or somewhere and are different for each method and need to be passed when method is called? i guess for sake of simplicity you hardcoded value here but i think that wont be true

[@MilanJovanovicTech]

Options pattern, and load the values when app starts

[@empireofhearts]

@@MilanJovanovicTech agreed. My question is geared towards the same interface used in both actual and cache class is not valid at that time as the contract for cache class requires cache time as param in the method

[@markus27183]

This is neat, but in the GoF pattern, the object has a reference/pointer to its own interface, rather than to a class which implements the interface. Also this decorator pattern has nothing to do with making the caching itself fast.

[@MilanJovanovicTech]

No, it has to do with making the repository fast using caching

[@pochtaliot]

Well, I always thought that introducing classes such as CachedMemberRepository is a Proxy pattern

[@MilanJovanovicTech]

Call it what you like, but we're on the same page when it comes to the implementation. Right?

[@pochtaliot]

@@MilanJovanovicTech if we call things whatever we like it's not a learning but exchanging of thoughts, right? And a good teacher is able to accept his mistakes, isn't he? What you've shown it's a proxy pattern not decorator as it was announced in title.

[@pochtaliot]

@@MilanJovanovicTech sorry if it looked like offending. I jus wanted to clarify

[@MilanJovanovicTech]

@@pochtaliot I researched this little, and I'm still of the opinion that what I showed is a Decorator. "Decorators are additive; meaning they only add new functionality by wrapping the function call and returning the original value. It can however do anything before or after that call. You can for example log every value when a function is called or dispatch an event. Just make sure to return the original value. Proxies are restrictive; meaning they can change the behavior of a function or even restrict calling a specific function by throwing an exception." Source: doeken.org/blog/decorator-vs-proxy-pattern

[@pochtaliot]

@@MilanJovanovicTech may be. But you need to check the uml structure too. And the proxy pattern's uml is fully regards to your code.

[@vipuldimri6571]

How to update or reset the cache if we update the customer ? Inside update , delete customer handler I am doing like this . await _repositoryManager.Save(); if (_repositoryManager.CustomerRepository is ICacheableRepository cacheableRepository) await cacheableRepository.ResetCache(string.Format(Customer.CacheKey, customer.Id));

[@MilanJovanovicTech]

Video on that coming out in a week 😅

[@murat.yuceer]

I prefer aspect oriented technique to cache

[@MilanJovanovicTech]

Why do you like that approach?

[@LimitedWard]

The only downside I see with this approach is the use of the concrete implementation of MemberRepository in your CachedMemberRepository. Won't that make it harder to unit test the CachedMemberRepository since you can't inject a mock implementation?

[@loam]

Hm, what if injecting IMemberRepository interface object to the decorator? Also, as far as I remeber, with ASP.Net DI container one can pass lambda directly to specify how the class will be instantiated.

[@MilanJovanovicTech]

Indeed, that's a good point. Later on in the video you can see I switched to IMemberRepository.

[@eduardoyupanqui]

We need to depend on abstractions, not implementations. Why not? public class CacheMemberRepository : IMemberRepository { private readonly IMemberRepository _memberRepository; public CacheMemberRepository (IMemberRepository memberRepository){} } public class MemberRepository : IMemberRepository { }

[@MilanJovanovicTech]

That's the implementation in the end

[@Real-Hindu-Us88]

Video is not clear

[@MilanJovanovicTech]

You could at least explain why

[@eobardthawne6903]

You are creating a Proxy pattern and not a decorator. Decorators work similar to how attributes extend functionality of existing action methods or controllers. In this example, you are creating a class which extends an existing class and adds new functionality, which is NOT a Decorator but a wrapper or proxy.

[@MilanJovanovicTech]

The majority of devs, including myself, know this as a decorator. Popular DI libraries implement this as a decorator and not a proxy. Call it what you wish, I'm not saying it's wrong. In fact, I only learned about the proxy pattern when publishing this video a year or so ago.

[@AsadujjamanShohan]

Thanks for your explenation, I am facing a problem when I am trying to register open generic class using decorate. This is the error I am getting. "Could not find any registered services for type". Not sure is it bug or my mistake. Here is my code. builder.Services.AddScoped(typeof(IMemberRepository), typeof(MemberRepository)); builder.Services.Decorate(typeof(IMemberRepository), typeof(CachedMemberRepository)); Do you have any idea why it's not working?

[@MilanJovanovicTech]

Why is MemberRepository generic though? 🤔

[@AsadujjamanShohan]

Yes your are right IMemberRepo and MemberRepo should not be generic. Actually I wanted to follow a generic repository pattern to make that dynamic. This is the actual code looks like. builder.Services.AddScoped(typeof(IGenericRepository), typeof(GenericRepository)); builder.Services.Decorate(typeof(IGenericRepository), typeof(CachedMemberRepository)); the error is occuring from 2nd line "Could not find any registered services for type IGenericRepository"

[@robslaney3729]

Consider GetRequiredService instead of using "!" to suffice nullability

[@MilanJovanovicTech]

Great tip! Thank you!

[@marwabenissa8955]

how can I do that ?

[@robslaney3729]

@@marwabenissa8955 GetRequiredService() is an extension method that throws if the requested "service" cannot be satisfied. That way, if can never return the default of "T"