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.
@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.
@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! 😊
@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...
@samuelterrazas3191
4 ай бұрын
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 KZitem ones that often don't work well or translate incorrectly.
@MilanJovanovicTech
4 ай бұрын
That one's gonna be tricky 😅
@milicabozic9897
Жыл бұрын
Awesome video, I really like the way you explain things 😊
@MilanJovanovicTech
Жыл бұрын
Thank you, Milica. I'm glad you found the video useful 😁
@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
@andersjuul8310
7 ай бұрын
I thought I'd seen you make a video on this -- and just what I needed. Brilliant, to the point as always. Thanks!
@MilanJovanovicTech
7 ай бұрын
Glad it was helpful!
@ahmadsabbagh1554
Жыл бұрын
Great work. Keep going 😍🥰
@MilanJovanovicTech
Жыл бұрын
Thank you so much! 😊
@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 😁
@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.
@adiazwise
Жыл бұрын
Thanks, Milan , excellent implementation of the decorator pattern.
@MilanJovanovicTech
Жыл бұрын
Awesome, glad you found it useful 😁
@EmptyGlass99
Жыл бұрын
Very clean and useful presentation.
@MilanJovanovicTech
Жыл бұрын
Thanks, I'm glad you liked it 😁
@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 😁
@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.
@daedwill
Жыл бұрын
Very clear explanation, thank you!
@MilanJovanovicTech
Жыл бұрын
Awesome, I'm glad you liked it! 💯
@beirinhaaa
Жыл бұрын
Very Nice explanation!!!! TKS for show many ways to do that!
@MilanJovanovicTech
Жыл бұрын
You are welcome!
@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
@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 !
@yunietpiloto4425
Жыл бұрын
Really nice stuff man, well explained, well presented...quality content, keep it up!
@MilanJovanovicTech
Жыл бұрын
Thank you so much! 😁
@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 😊
@NAEL4SLR
Жыл бұрын
Awesome contents! Thanks for sharing
@MilanJovanovicTech
Жыл бұрын
Thanks for watching!
@abdelrahmanmahmoud2285
Жыл бұрын
Awesome video , keep going
@MilanJovanovicTech
Жыл бұрын
Thank you!
@agustinmolina5170
6 ай бұрын
i give you like from start because i see you like Warcraft!!
@MilanJovanovicTech
6 ай бұрын
Haha, used to play a lot back in the day 😁
@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 😁
@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.
@taner-saydam
Жыл бұрын
An ingenious way, thanks🤩🤩
@MilanJovanovicTech
Жыл бұрын
Glad you like it!
@taner-saydam
Жыл бұрын
@@MilanJovanovicTech I live you all videos. Thanks a lot. Really ☺
@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
@ahmedanwer1767
Жыл бұрын
Awesome
@MilanJovanovicTech
Жыл бұрын
Thanks!
@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
@sandorvarga7437
Жыл бұрын
Success.
@MilanJovanovicTech
Жыл бұрын
💯
@davidwilliss5555
7 ай бұрын
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
7 ай бұрын
Good suggestion
@vivekkaushik9508
Жыл бұрын
Brilliant.
@MilanJovanovicTech
Жыл бұрын
Thank you very much! 😁
@xantari79
5 ай бұрын
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
5 ай бұрын
Maybe, but it's just a few basic shortcuts
@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
@andresbeltran5779
Ай бұрын
Excellent
@MilanJovanovicTech
Ай бұрын
Thanks!
@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.
@InshuMussu
8 ай бұрын
i am a fan of you ❤
@MilanJovanovicTech
8 ай бұрын
Thank you! :)
@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.
@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
@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
10 ай бұрын
Semantics. Big question is: “Does it achieve the desires outcome?”
@eobardthawne6903
6 ай бұрын
Thanks for pointing this out. I was thinking the same.
@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.
@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 😁
@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.
@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 :)
@eddypartey1075
11 ай бұрын
Milan, I'm not that experienced but why don't you use async/await in CachedMemberRepository?
@MilanJovanovicTech
11 ай бұрын
Returning a Task is enough
@androidsavior
4 ай бұрын
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
4 ай бұрын
You're welcome to just have caching in the repo
@andersjuul8310
7 ай бұрын
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
7 ай бұрын
A decorator of what? If it's a decorator solving technical concerns, then it's probably more appropriate to place it in Infrastructure
@andersjuul8310
7 ай бұрын
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!
@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
Жыл бұрын
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.
@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!
@ugurcan4638
8 ай бұрын
So helpful video series. Thank you. I want to ask what is the shortcut keys at min 6:43 (navigating to Program.cs).
@MilanJovanovicTech
8 ай бұрын
Ctrl + T?
@ugurcan4638
8 ай бұрын
Thanks a lot@@MilanJovanovicTech
@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
@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
@murat.yuceer
Жыл бұрын
I prefer aspect oriented technique to cache
@MilanJovanovicTech
Жыл бұрын
Why do you like that approach?
@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
@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
@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
@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 KZitem algorithm for recommendation. Really enjoy your content. Hope your channel will growth up even faster than 233x;)
@MilanJovanovicTech
Жыл бұрын
@@vAmp1que I hope so to 🍀
@thegaribovv
5 ай бұрын
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
5 ай бұрын
It would be smart to pass in the cache key as an additional argument
@thegaribovv
5 ай бұрын
@@MilanJovanovicTech Then it will broke the repository pattern
@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!
@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 🙏👌
@shabtaiben-david8173
4 ай бұрын
what about the case I need to refresh specific id data, i.e. ignore cached instance?
@MilanJovanovicTech
4 ай бұрын
kzitem.info/news/bejne/upp7yHhrbJVpdag
@shabtaiben-david8173
4 ай бұрын
@@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...
@vincenthamelin6115
7 ай бұрын
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
7 ай бұрын
kzitem.info/news/bejne/upp7yHhrbJVpdag
@sameerpanicker7452
2 ай бұрын
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
2 ай бұрын
That's what you'd end up with... Perhaps there's some clever way to implement this with attributes.
@sameerpanicker7452
2 ай бұрын
Thank you Milan for the suggestion. I will have a look.
@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!
@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!
@kenjiobara
Жыл бұрын
how to generate construct using the new sugar syntax?
@MilanJovanovicTech
Жыл бұрын
What did you mean to say here?
@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.
@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.
@jeetsingh4588
3 ай бұрын
what if your generic repository have predicate/func type parameter, how you will make a cache key unique in that case?
@MilanJovanovicTech
3 ай бұрын
Pass the cache key as another argument
@chriscardoz
Жыл бұрын
Castle proxy ? Any drawbacks ?
@MilanJovanovicTech
Жыл бұрын
Haven't used it, so I wouldn't know
@nasih6474
9 ай бұрын
Can i get this source code if i join the patreon?
@MilanJovanovicTech
9 ай бұрын
Yes, that's the whole point :)
@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 😅
@empireofhearts
4 ай бұрын
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
4 ай бұрын
Options pattern, and load the values when app starts
@empireofhearts
4 ай бұрын
@@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
@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
@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.
@eobardthawne6903
6 ай бұрын
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
6 ай бұрын
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
10 ай бұрын
how can I do that ?
@robslaney3729
9 ай бұрын
@@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"
@radeksendecki9922
Жыл бұрын
Great work. As always clearly presented in the simplest form, but covering the essence of the subject.
Пікірлер: 218