You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am developing an app where for various reasons, I do not want the model layer to implement INPC or INCC. The main reason is I want this model to live in a different library project that will be used in context where implementing these would be overkill and unwanted + other constraints I will likely deal with. Basically, it's annoying to do it that way on the model.
So the solution in mvvm is to have the view model implement the INPC and offer collections with INCC so they can be bound by the views. The problem is it leads to a ton of wrapping code. Luckily, the mvvm community toolkit already offers a reasonable solution by doing something like this:
publicintRank{
get =>_globalSaveData.Rank;
set =>SetProperty(_globalSaveData.Rank,value,_globalSaveData,(x,y)=>x.Rank=y);}
This would work: the view can bind to this, you can edit it with a numeric up down or whatever and it would change my backing model.
The problem I have with this is it's 6 lines for essentially just a property wrapper. The file I pulled this example has 14 fields that needs this code. That's a lot of code for doing the same thing over and over and while it's a lot better than alternatives, it's still too much for me.
The ObersableProperty attribute cannot help here: I can only make it call the basic version of SetProperty where it's just a straight property with no backing model field. Here however, I would like the ability to pass parameters to the attribute to tell it that "Hey, yes I want you to generate the property, but also to just ref this backing model field".
For this specific case, it would need to know the underlying modal (here _globalSaveData) and the field I want to wrap (here _globalSaveData.Rank), but I cannot tell it these information. There could also be an argument that the callback could be provided, but for this specific problem, it's not necessary.
I just find interesting because the documentation specifically talks about that this overload of SetProperty is intended for this usecase, but that the source generators do not support it currently. This indicates that I might not be alone having that thought and I am opening this thread to see if I am not alone with this need cause it would solve the biggest issue I have with this wrapping approach and it's something I experienced quite a fair bit in the past. Sometime, you simply don't want or can't implement INPC in the model for various reasons and I think having a way to eliminate the mapping to be huge for these cases.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I am developing an app where for various reasons, I do not want the model layer to implement INPC or INCC. The main reason is I want this model to live in a different library project that will be used in context where implementing these would be overkill and unwanted + other constraints I will likely deal with. Basically, it's annoying to do it that way on the model.
So the solution in mvvm is to have the view model implement the INPC and offer collections with INCC so they can be bound by the views. The problem is it leads to a ton of wrapping code. Luckily, the mvvm community toolkit already offers a reasonable solution by doing something like this:
This would work: the view can bind to this, you can edit it with a numeric up down or whatever and it would change my backing model.
The problem I have with this is it's 6 lines for essentially just a property wrapper. The file I pulled this example has 14 fields that needs this code. That's a lot of code for doing the same thing over and over and while it's a lot better than alternatives, it's still too much for me.
The ObersableProperty attribute cannot help here: I can only make it call the basic version of SetProperty where it's just a straight property with no backing model field. Here however, I would like the ability to pass parameters to the attribute to tell it that "Hey, yes I want you to generate the property, but also to just ref this backing model field".
For this specific case, it would need to know the underlying modal (here
_globalSaveData
) and the field I want to wrap (here_globalSaveData.Rank
), but I cannot tell it these information. There could also be an argument that the callback could be provided, but for this specific problem, it's not necessary.I just find interesting because the documentation specifically talks about that this overload of SetProperty is intended for this usecase, but that the source generators do not support it currently. This indicates that I might not be alone having that thought and I am opening this thread to see if I am not alone with this need cause it would solve the biggest issue I have with this wrapping approach and it's something I experienced quite a fair bit in the past. Sometime, you simply don't want or can't implement INPC in the model for various reasons and I think having a way to eliminate the mapping to be huge for these cases.
Beta Was this translation helpful? Give feedback.
All reactions