hi Aaron, I don't sell MCM and I'm not trying to convince you it's better than anything else. I have seen some frameworks starting with CAB & SCSF (Composite UI Application Block & the Smart Client Software Factory), XAF (eXpressApp Framework by DevExpress)
ending with some MVVM implementations. They are powerful but slow, the configuration effort is immense, there are many rules and you need months to master them.
Creating MCM I had some goals: extensibility, testability, simplicity and as few rules as possible.
Using asynchronous message communication instead directly method invocation and referencing objects by interfaces i provide losse coupling - basis for extensibility. To extend the system you need only provide new components and connect them with the message
channel - just like settle additional village residents.
Providing commands with arguments i isolate their environment. I can simulate each command parameter for unit tests.
An MCM Application consists only of a message channel (a loop in a dedicated thread) and components. Components subscribe the message channel, create commands for working and send messages. The whole rest you create on your own. The framework is small, so
the learn effort is small. There is no overhead, you can freely and transparently create framework extensions.
Why do I use custom commands instead Threading.Tasks?
My command has some feature I personally like - instead providing the working method with a delegate I can inherit my command from a generic class and overwrite the ExecuteCore() method. It looks cleaner ;-)