-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Attribute based caching #362
Comments
Hi @adnan-kamili , the main problem with attribute-based caching is that since it's not based on "normal" code (eg: inheritance, etc) or things like source generators, it requires what is known as IL weaving/rewriting. This means that PostSharp will change the generated IL with custom steps in the MSBuild pipeline, and doing so it's not the job of a caching library (or any library in general). Having said that, what I would see as a possible solution is this: if PostSharp allows some extensibility, for example by having an I don't know if such a thing exists or if it's possible to do, but that is the only way I can see this working. Do you know if something like that abstraction exists so that I may be able to plug into that? Thanks! |
Thank you for your response! I came across an implementation leveraging DispatchProxy that was generated by LLMs. While I’m not an expert in this area, I’m curious whether this approach would be viable and what potential performance implications it might have. I’d appreciate your insights on this. |
If using PostSharp Essentials (which is free) is an option, it provides the OnMethodBoundaryAspect, which can be utilized to create an aspect for caching. You can find more details in the documentation: https://doc.postsharp.net/il/custompatterns/aspects/tutorials/method-decorator. However, it’s worth noting that PostSharp Essentials does not support asynchronous methods, so this limitation might make it an unviable option. |
I recently discovered the interceptors feature introduced in .NET 9.0, and it seems like they could offer a more efficient approach to implementing attribute-based caching. Since interceptors work at compile-time, they may provide better performance compared to runtime-based solutions. You can find more details here: |
Thanks for the info and links: while super busy with finishing v2 in the last months, I totally forgot about the new shiny interceptors. |
Problem
We are exploring migrating from PostSharp.Patterns.Caching to your excellent caching library. However, we rely heavily on attribute-based caching in our current implementation. In PostSharp, simply adding a [Cache] attribute to a function automatically handles caching, significantly reducing repetitive code.
While your library provides powerful caching capabilities, the absence of attribute-based caching requires us to write additional boilerplate code for cache management. This makes migration more cumbersome and less seamless compared to our current setup.
Solution
Do you have any plans to introduce attribute-based caching? This feature would:
1. Simplify the integration process.
2. Reduce boilerplate and repetitive code.
3. Align with the workflows of developers accustomed to declarative caching mechanisms.
Additional Information
We believe adding attribute-based caching would enhance the library’s usability and attract developers looking for a clean, declarative approach. It could potentially work by allowing developers to annotate methods with an attribute like [Cache], with options for configuration (e.g., expiration, cache key strategies, etc.).
Looking forward to hearing your thoughts on this!
The text was updated successfully, but these errors were encountered: