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
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!
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...
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 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.
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 UA-cam ones that often don't work well or translate incorrectly.
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!
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.
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!
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 👍
@@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.
@@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 !
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
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
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.
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
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?
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.
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?
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.
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.
@@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...
@@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?
@@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.
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? :)
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!
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.
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.
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.
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?
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 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
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.
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.
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.
@@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.
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!
Talking about decorator pattern, why you dont use a base decorator class , every concrete decorator must implements base decorator instead the concrete component
@@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
@@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 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
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 { }
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.
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.
@@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.
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));
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?
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.
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?
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!
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
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
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!
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?
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.
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.
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 thx man. And thx UA-cam algorithm for recommendation. Really enjoy your content. Hope your channel will growth up even faster than 233x;)
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?
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.
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?
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"
@@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"
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!
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
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
Excellent pattern indeed. And you can keep reusing it all over the place.
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!
Of course, if you have multiple services running then you need a distributed cache.
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...
There are many other use cases for Decorators, such as: logging, validation, resource-based authorization...
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.
You're using HybridCache from preview?
@@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.
Great work. As always clearly presented in the simplest form, but covering the essence of the subject.
Thanks a lot, Radek 😁
Awesome video, I really like the way you explain things 😊
Thank you, Milica. I'm glad you found the video useful 😁
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 UA-cam ones that often don't work well or translate incorrectly.
That one's gonna be tricky 😅
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!
It's an entirely different type of caching, so we should be careful. I think it's more appropriate for caching HTML output.
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.
Pretty cool, I'm glad you ran into this video then 😁
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!
Awesome Sergio, glad you can apply this to your project 😁
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 👍
But question : why add Scrutor when you had it working already? Adding third party for no extra benefit doesn't seem smart.
Just wanted to show multiple options, by introducing Scrutor. In general, I would use Scrutor by default since it's more feature rich.
@@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.
Great work. Keep going 😍🥰
Thank you so much! 😊
Very clean and useful presentation.
Thanks, I'm glad you liked it 😁
Neat and tidy ! It's great you have shown few ways for service registration.
Which did you like the most?
@@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 !
Really nice stuff man, well explained, well presented...quality content, keep it up!
Thank you so much! 😁
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
Agreed, plays very nice with unit testing
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
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?
Maybe, but it's just a few basic shortcuts
i give you like from start because i see you like Warcraft!!
Haha, used to play a lot back in the day 😁
Awesome contents! Thanks for sharing
Thanks for watching!
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
Thank you for watching them! 😊
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.
Good suggestion
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
Awesome, I'm so happy you found this video helpfuln
caching is about as practical as you get
Awesome video , keep going
Thank you!
Mostly recommended cache is distributed cache like redis , mongodb etc rather than mem cache
If the use case is simple , then it makes sense to have this memcache 😊
You won't need it in a non-distributed system
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?
You can inject the HttpContext which should have the headers present perhaps, and check if you should use cache or not
Milan, I'm not that experienced but why don't you use async/await in CachedMemberRepository?
Returning a Task is enough
Very clean code. Can you please also upload your code to github repository.
I share the code with my Patreon supporters. But there are some examples available on my GitHu that you can look at :)
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.
Yeah, it does seem that this is the "Proxy" pattern after much comments on this video.
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 ?
You're welcome to just have caching in the repo
So helpful video series. Thank you. I want to ask what is the shortcut keys at min 6:43 (navigating to Program.cs).
Ctrl + T?
Thanks a lot@@MilanJovanovicTech
Milan pls consider to make a discord server. Would be awesome.
Good idea Martin. I'm definitely going to do it at some point.
Brilliant.
Thank you very much! 😁
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?
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.
@@MilanJovanovicTech Thanks for the answer. Btw. what keyboard do you use?
@@TheAproeX Nothing fancy: Logitech K120
Gets the job done 😁
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.
what about the case I need to refresh specific id data, i.e. ignore cached instance?
ua-cam.com/video/YdEbD53c8Bs/v-deo.html
@@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...
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?
Invalidate the cache after adding a member
@@MilanJovanovicTech Thank you!
How do you add the cached member to change tracking?
dbContext.Attach(member)
@@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?
@@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.
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? :)
A decorator of what? If it's a decorator solving technical concerns, then it's probably more appropriate to place it in Infrastructure
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!
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.
Too much generic will constrain your design, so tread lightly
@@MilanJovanovicTech Thank you for your answer. I will take it in mind for my next development
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.
Thanks for pointing that out!
how to generate construct using the new sugar syntax?
What did you mean to say here?
What abount entry invalidation? how do you implement it with this approach?
Simplest would be straight in the CachedMemberRepository. Decorate the other methods the make changes, mainly Update, and invalidate the cache.
@@MilanJovanovicTech Thanks!
Decorator pattern is really nice, but there is a lot of boilerplate. It would be nice to see a SourceGenerator for this pattern.
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.
Castle proxy ? Any drawbacks ?
Haven't used it, so I wouldn't know
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?
That's what you'd end up with... Perhaps there's some clever way to implement this with attributes.
Thank you Milan for the suggestion. I will have a look.
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
Options pattern, and load the values when app starts
@@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
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.
No, it has to do with making the repository fast using caching
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.
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.
@@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.
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!
Semantics. Big question is: “Does it achieve the desires outcome?”
Thanks for pointing this out. I was thinking the same.
Talking about decorator pattern, why you dont use a base decorator class , every concrete decorator must implements base decorator instead the concrete component
What would be the benefit of that approach?
@@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
Well, I always thought that introducing classes such as CachedMemberRepository is a Proxy pattern
Call it what you like, but we're on the same page when it comes to the implementation. Right?
@@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.
@@MilanJovanovicTech sorry if it looked like offending. I jus wanted to clarify
@@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
@@MilanJovanovicTech may be. But you need to check the uml structure too. And the proxy pattern's uml is fully regards to your code.
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
{
}
That's the implementation in the end
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.
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.
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.
Smart!
this is what I was looking for
I was looking for that as well. Would be a nice topic for a future video
How would you implement that ? Would love to know
@@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.
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));
Video on that coming out in a week 😅
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?
It would be smart to pass in the cache key as an additional argument
@@MilanJovanovicTech Then it will broke the repository pattern
Can i get this source code if i join the patreon?
Yes, that's the whole point :)
I prefer aspect oriented technique to cache
Why do you like that approach?
Hi Milan, Requesting video on Concurrency token and Handling Concurrency Conflicts by using EF core.
All right Amit, I added it to my production list 😁
Video is not clear
You could at least explain why
Awesome
Thanks!
Very clear explanation, thank you!
Awesome, I'm glad you liked it! 💯
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.
Of course, this is just one piece of the puzzle.
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?
I didn't need to do something like this before
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!
Yes, you need to include anything that can change in the cache-key
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
ua-cam.com/video/YdEbD53c8Bs/v-deo.html
I thought I'd seen you make a video on this -- and just what I needed. Brilliant, to the point as always. Thanks!
Glad it was helpful!
what if your generic repository have predicate/func type parameter, how you will make a cache key unique in that case?
Pass the cache key as another argument
Great video ! However it would be worth mentioning, that we should keep in mind some cache invalidation strategy. Thanks for Your work :)
Definitely, I kind of failed to cover that aspect properly. I'll make it right in a future video
That Scrutor implementation seems more flexible which is really cool.
I really like it also, easy to write when you have a lot of dependencies
@@MilanJovanovicTech Thank you for showing it
Very Nice explanation!!!! TKS for show many ways to do that!
You are welcome!
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
Yes
@@MilanJovanovicTech so in your example you have used it vice versa
so is this decorator pattern too?
Thanks, Milan , excellent implementation of the decorator pattern.
Awesome, glad you found it useful 😁
Awesome loving your videos! so happy I stumbled upon your page
Thanks a lot Shane, I'm glad you're loving the content 😊
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!
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?
@@MilanJovanovicTech I Need to think this one through clearly. Appreciate your thoughts on this!
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.
Why wouldn't it work? Because EF wouldn't track it?
We can fix that easily with Attach.
@@MilanJovanovicTech Ok yes it should work with Attach! Thanks
Well done, comprehensive and straighforward as always in your videos. Besides, one should consider using ValueTask instead of Task in such cases.
Why do you think a ValueTask is a good fit there? 🤔
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.
I guess, when updating the entry (which is Member in this case), cache also should be updated. Is it so?
Indeed, that should be the case. Or rather - we can just clear the cache, and let the next query fill it.
@@MilanJovanovicTech Thanks for the reply 🙏👌
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.
I think that updating the cache when you update the Entity is a viable option. We can usually live with a short stale cache.
@@MilanJovanovicTech thx man. And thx UA-cam algorithm for recommendation. Really enjoy your content. Hope your channel will growth up even faster than 233x;)
@@vAmp1que I hope so to 🍀
An ingenious way, thanks🤩🤩
Glad you like it!
@@MilanJovanovicTech I live you all videos. Thanks a lot. Really ☺
i am a fan of you ❤
Thank you! :)
Excellent
Thanks!
Success.
💯
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?
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.
Indeed, that's a good point. Later on in the video you can see I switched to IMemberRepository.
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?
Why is MemberRepository generic though? 🤔
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"
Consider GetRequiredService instead of using "!" to suffice nullability
Great tip! Thank you!
how can I do that ?
@@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"
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!
Thanks a lot, Kamil! I'm glad you liked it 😁