MVVM toolkit receive method of messaging service
Hi guys was wondering if there is a convention for using messaging service?
implementing the irecipient of the message makes a Receive method to execute when the message is received (duh) but if there are many receive methods its quite ambiguous
is there a way around this? can i put receive methods at the bottom of the class file that pass and call an aptly named method that is higher up for more code readability? would this effect performance and memory?
an example would be
something like
public class Foo: IRecipient<BarMessage>
{
public void Receive(BarMessage message) => private void DoBarMessage(message);
}
25 Replies
It won't affect performance probably
It'll barely affect the size of the dll
There are no runtime allocations to calling methods
If you find that easier to understand, go for it
There's nothing wrong with it
You do get the flexibility of being able to use the "aptly named" method directly instead of one of the overloads too
You can use
partial class
how can i use them directly? instead of these receive methods
could i get a further explanation? im not sure what these are to be honest haha
You asked for more code readability and putting them at the bottom ... I told you how you can separate them even in another file
A
partial class can be written in as many files as you likeis a partial class something that sort of combines? at run time?
so i can dump all the receive methods in a partial Foo elsewhere
and have other logic in another partial Foo
No, it is only syntax sugar - internally it will be merged together and gets compiled
The runtime will not know if the class was a partial class
oh sorry yeah tahts what i meant
compiliation would combine all of these into 1 class im guessing
thats pretty interesting actually
It is one class - only the declaration has several parts
can i reference a method that is in one partial class from the other one
or properties
you have not multiple classes with partial. it is one and only one class - it is only the declaration of this one and unique class that is split in several parts
As a very long story you write down in four books. It is one story
There is no difference if you put it all together in one file/declaration or in parts - it is the same - so you can reference any property, field or method from any of the parts
oh thats really interesting
i think when i go and clean up my code im gonna put all the receive methods in a singular partial class and the rest can be in another one
group them up you know
thanks for the help
i didnt know you can do that haha
You are using the mvvm toolkit?
yes
Did you ever uses the
ObservableProperty attribute and the generated property?i use it often
its easier than making the property haha
Then you do know that fact of that partial class
š
Because you used it all the time
yea i see that my class is partial i just never knew what it meant haha
the IDE told me to write it so i did
š
should i close this query now?
If you got your answer, why not. It is your question
š
thanks
By making them public
I dont understand
If i make a public method that isnt named receive but takes the message as an arg it would work?
It won't, but you then could call that instead of Receive if you wanted to