-
-
Notifications
You must be signed in to change notification settings - Fork 405
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
Call data portal operation methods explicitly #4359
Comments
"and code to implement the interface implicitly" - I think you meant "explicitly". What would be the trigger for the SG? The existence of the DP attribute(s) on the method within the type? |
BTW you'd want to have a check to make sure the name you generate, |
First time I saw PersonEdit as partial class. |
Is the explicit interface implementation only to make it look like the method is used? |
At a minimum, yes. This causes AOT and VS to think that the method is viable. However, I am hopeful that we can go beyond this point and optimize the invocation of the operation methods by generating client-side extension methods that "know" which overload to invoke. The idea goes like this:
The only place reflection is needed would be step 4, and even there it would be a direct invocation instead of the overload scanning and scoring that exists currently. |
Today, data portal operation methods are private and are called dynamically by the data portal. They are identified by attributes such as
Fetch
orUpdate
.This is a problem because AOT will optimize these methods out of the codebase. It is also a problem because Visual Studio grays out the code, thinking it is never invoked.
Using a code generator, it might be possible to explicitly invoke these methods. Here are my initial thoughts on how such a thing might work.
For example:
The text was updated successfully, but these errors were encountered: