This project is read-only.

Why not just use .Net 3.0?

Jan 24, 2013 at 4:29 PM

I understand that MCM is written on the 2.0 Framework, but so is 3.0...  3.0 just introduces WPF, WCF, and WF...  And incidentally the ICommand pattern that is backed and supported by Microsoft.

Really, why would I want to use this stuff?  What makes it so much better than what the guys at MS wrote and have been supporting for the last 6 years?

Just wondering

Jan 24, 2013 at 10:31 PM

hi, at first thanks for reading so far... ;-)

indeed this is an old stuff but the new stuff is an old stuff only presented in a different way.

This framework does not use any special GUI technology, it does not communicate with other components using WCF. It uses plain old ThreadPool for asynchronous operation and a service container.That's why in my opinion the .NET 2.0 is enough.

Combining components together and communicating using asynchronous messages you create a village and its residents or how a programmer would say - a state machine. The village can turn into a small town, a small town can turn into a metropoly. The state machine can grow unlimited but their components still work loose coupled, independently.

The simplicity of this framework and easy usage pattern are strength of this framework. The drawback is - you create many classes for each use case (however actually I use a code generator to generate them) but the real advantage is when you work in a team, you don't need to merge big, fat objects but you copy the whole components, messages and commands from one place to the other.

It really works :-)

Jan 24, 2013 at 11:10 PM

So, is this then a .Net 2.0 only framework.

If someone is using .Net 3.0 should they just use .Net commanding

What is the difference between what .Net commanding does and what yours does?

Jan 25, 2013 at 9:02 AM

I see .NET commanding as a way of connecting the UI with the Model using Binding. MCM should be placed in a deeper layer - as a state machine.

  1. You press a button on the UI
  2. A bounded to the button {{System.Windows.Input.ICommand}} is executed. It sends a message asynchronously to the message channel.
  3. Message channel broadcasts the message to all subscribers.
  4. All methods marked with the MessageSubscriberAttribute and having the parameter of type of the broadcasted message or its descendants are invoked. These methods are registered during invoking the ComponentContainer.Add() method
  5. Registered components providing these methods (a) update their state according to the incoming messages or (b) execute IMcmCommand asynchronously for long lasting operations (the message channel should not be blocked or broken)
  6. Registered components send additional messages (command response, state changed) to the message channel
  7. Registered components update {{System.Windows.Input.ICommand}} according to the incoming messages or state of other components.
  8. {{System.Windows.Input.ICommand}} updates UI using Binding

You can place the information as a message property, but you can also broadcast an empty message and access other components in the comonent container using its First(), FirstOrDefault() or Many methods and check their current state.

You don't need to make for every operation in system a dedicated set of Request/ResponseMessage, Command, CommandArgument, CommandResult and a Component classes. However for asynchronous operations it would be highly recommended.

Indeed making these classes is a pain in ass but currently I use a code generator. After defining only the Prefix (i.e. LoadUsers) all the 5 classes are generated automatically.