On a project I’m working on I’m trying to develop a generic mechanism for sending back messages from anywhere in the code base to the front end for possible logging, displaying to the user etc.
Messages could be sent because of an error/exception, to report progress etc. Initially I thought of using something like log4net to report the message data and have a custom appender at the application level to consume these messages and then display them/log them as appropriate. However I’m not sure that this is the best approach because of a couple of issues
1) The project is split across a number of separate assemblies and I’ve seen that there are issues with configuration of log4net across multiple dlls.
2) This messaging scheme is more than just logging, so using a logging framework may be too restrictive.
At the moment I’m using C# custom message events to send data from assemblies and registering a handler at the application level to capture them.
However I’ve realized that the the Messenger class in MVVMLight is exactly what I’m looking for, a way to send a generic data packet (class) across assemblies. But because I could be sending messages from model code I’m wondering if this is adding unnecessarily dependencies to MVVMLight in to the model code.
My impression is that the Model code should be as dependency free as possible so that it could be dropped into any application framework without modifications.
What do you guys think?
If that’s what you’re trying to do then you should use the Messenger class.
How likely is it (really) that the model code is going to be used by another application? If it’s something generic (user preferences, security, etc) then you might want to use it elsewhere but if you’re providing bespoke business data then YAGNI.
From a good practices perspective I’d suggest doing something like this:
Register the MessengerProxy in MVVM Light and have it injected into the constructor of your Model classes. In my model class, above, I inject the interface into the constructor. This gives me access to the Messenger but allows me to change the underlying implementation if I need to later on.