This project is read-only.

Can you take a shot at comparing to Reactive Extensions (Rx) features?

Feb 5, 2013 at 9:02 PM
I know it won't be easy, but could you take a shot at comparing it to: Rx

The Rx is more the "Boeing 747" in the room. I like your simple MCM-pattern approach and your "village to city" metaphor is very applicable these days. I also like the .NET 2.0 simplicity that enables it to run almost anywhere. So, all I'm trying to do before I get going with MCM is get a grips on where its strengths and limitations are -- and whether polo is going to suddenly evaporate and leave us with a pile of (gold) dust :-)

Thanks for any tips,
Feb 7, 2013 at 4:57 PM
"I'm sorry Dave, I'm afraid I can't do that..." - said HAL 9000 in the 2001: A Space Odyssey... ;-)
I don't know Rx and I don't use it. Therefore comparing these both products would be very hard. It's not so bad if I evaporate. All what is left would be a bunch of classes communicating with each other mostly using messages. MCM is a software pattern, just like MVVM, MVC and others and the way you use it depends on you.

Please refer to the Hello World example for better understanding.

There is a container. It contains components. Some components are workers (Component 1) other updates UI (Component 2).

If you need logging functionality, you add Component 3 to the container. After it receives the HelloResponseMessage it stores the message content to the log file.

If you need "Work in progress" reporting, you add Component 4 to the container. After it receives the HelloRequestMessage, it sets its IsWorking property to true. After receiving the HelloResponseMessage IsWorking is set to false. Each change to IsWorking is reported by sending the IsWorkingChangedMessage.

A Component 5 waits for the IsWorkingChangedMessage and updates UI according to it.

This structure can grow and grow. New components can be added, old ones can be removed. Components can refer to each other directly just like Services in ServiceProvider or can communicate indirectly using messages.

In the Hello World example only Component 1 is using commands for asynchronous operation. All other components work synchronously - after receiving a message they update their state on the same thread (i.e. Component 2).
Feb 7, 2013 at 7:15 PM
Edited Feb 7, 2013 at 7:15 PM
OK, HAL, I was afraid of that... Well, if you did vaporize, all those classes would be left around with no (up) dates. Anyway, thanks and I'll take a closer look. One last dumb question: is your mcm network-aware, meaning, can I put producers and consumers on other ends of a wire in a pattern-conform manner? Example?

Thanks again!
Feb 7, 2013 at 7:30 PM
No, there are no network components. That's why I mean, my vaporization cannot hurt anybody. You must build your own producers and consumers and wrap them into components. A component after receiving a message, invokes a particular method in the producer, the producer sends it over the wire. On the other wire side the consumer receives the signal and invokes an event. The event is intercepted by the component wrapper which sends a message.

This is not an easy drag'n drop solution but it provides a clear two layer communication with components as a higher layer and the producer/consumer implementation as a deeper one.