MVC + M new article

[Marlon Grech]

Hey Guys,

I wrote a post on how you can put your WPF MVC on steroids... have a look and let me know what you think....
Do download the source code because I think that I express myself better in C# than in English.... C# is much more explicit :)

If you like it ... go ahead and Kick it :)

Thanks guys, you're the best

--
Regards
Marlon
Blog - http://marlongrech.wordpress.com/
WPF Controls Library - http://www.codeplex.com/avaloncontrolslib

[Josh Smith]

Great article.  I'm looking forward to your reply to my questions...

[Marlon Grech]

"I'm looking forward to your reply to my questions..."

What do you mean?

[Josh Smith]

I posted some questions in a comment on the article you wrote.

[Marlon Grech]

ow.... ok let me have a look

[Marlon Grech]

Josh, I just sent a comment back... Please let me know if I was clear... Thanks

[Josh Smith]

Nice.  I just replied to your comment.  thanks

[Marlon Grech]

and I just did again... hehe, I want to convience you :D

[Zhou Yong]

The message type of handling let me think of nitty gritty windows message handling, glumsy and bloated default DefWindowProc etc:)

 I'd rather prefer to strongly typed callback instead.

Yong

[Marlon Grech]

You have a very valid point there. Yet that is an implementation detail... You can easily change the mediator to use delegates instead of the messages that I am using.

What I tried to show in the post is more the Concept of having the Mediator that makes the communication between the controllers easy and loosely coupled...

I am currently working on another example for this....

[Marlon Grech]

Marco,

I was thinking on what you said and I thing that this can be implemented really easily....

The Register method of the mediator would have the following Signature...

Register( IDictionary<string, Action> callbacks);

so that one can do the following

Register( new Dictionary<string, Action>
{
     {Messages.SelectionChanged, delegate(object obj){ //DoSomething here  } }
}

Yet I think still you would need a string for the messages. The big benefit would be to get rid of the switch statment that the collegues would have...

What do you think?

[Zhou Yong]

indeed, but I'd rather prefering using Int32 const such as public Int32 GetAllProducts = 0x0001;

 

But anyway, when the apps gets bigger, we need more msgs, that's why I think there might be other better solution

 

What do you think about this?

[Marlon Grech]

Well you have to be careful not to over do it with messages. Usually a message is related to a feature so you have a message per feature (obviously there are cases where this does not apply).

Right now, I am using this in one of the projects at work. The project I am working on is a System Profiler so you can imagine how much stuff there is...

With this system we can break things down into small pieces because we know that the communication will be very easy between the entities. This is making the application much easier to change and much more code reusablity is being done. When things are broken down into small pieces then you can easily reuse code.

So I beleive that with this design you can have a "loosely coupled and high cohesion" code base.

Yet, as I already said one should be careful... Why should you break down a module if you know you are not going to reuse it! So you should break down thing only if there is a need.

Well after all this is only one idea..... There are loads of others out there :)

[Josh Smith]

I think having a limited number of messages makes sense, but if that "limited number" becomes very large because the app is very big and complicated, then it can get confusing.  I worked on a system with a somewhat similar pattern in it, and it was tough for new people on the team to understand the object relationships since they were all based on broadcasted messages.  It was a very big system, and had many features.  Visual debugging wasn't exactly straightforward, either.  My point is, the usefulness of this pattern (just like any other) is a function of many factors, including the code base size.

[Zhou Yong]

Good point, Josh, that's why when Marlon comes up with the message idea

I start to think of WIN32 programming and dealing with Window messages:)

 

It's a terrible experience really:)

[Marlon Grech]

Ok, so the messages is the problem... One may be afraid of having too many messages....

Yet if we think about this, the Mediator is a kind of a Publisher Subscriber i.e Events in C#.

Do you have to many events in a control? For every feature (ex.Expanded), I have an event. Is this too much?

This is the same thing. Instead of having the events we have messages. If we go for the approach of having delegates for registration i.e

Register( IDictionary<string, Action> callbacks);

Then there is no need to do the WIN32 like handling (yet again this is purely implementation details. The concept does not change).

What do you guys think?

[Josh Smith]

The events of a control all relate to that single control, they all fit under one "umbrella."  The messages in an application relate to all aspects of the entire application. You can end up with hundreds of messages, and most of them have nothing to do with each other, in terms of who sends them, who listens to them, and when they are broadcast.  It's not a good analogy to compare a control's events to an application's set of messages.

[Josh Smith]

Also, on a side note, you must be sure to prevent the message broadcaster from creating a memory leak.  Either the Colleague objects must unregister themselves when they are going to die, or the Broadcaster must use WeakReferences to point to the Colleagues. Or, you could use the WPF WeakEvent pattern, perhaps.

Josh

[Marlon Grech]

What is stopping us from putting the messages under an "umbrella" as well... Put messages related to each other in a class and the others in other classes. It doesn't matter how you structure them. (and please keep in mind that this is only for Communication of Controllers not the whole application... well if you want this pattern is abstract and can be used for any part of the system but as I see it, this fits best for Controllers)

With regards to who is sending the message. Who cares! That's the whole point of this. As long as you registered to a message you do not care who will be sending it and when.

With regards to the Unregister definitely you must do unregister from the Mediator. Yet usually since this is UI related and the controllers would all be living together at the same time. Yet yes, I agree, you have to unregister from the mediator but that is not a problem.

Guys, it's getting a bit warm here. I love this conversation :D

[Josh Smith]

I guess I was projecting your usage of Mediator into the bigger world of message broadcasting.  My bad.  You're right, if this is just limited to communication between controllers, then it wouldn't be too hard to keep the number of messages low.  But, then you would have this system where the Controllers have this message broadcasting thing going on, and it isn't anywhere else in the system.  That probably wouldn't last too long, because other developers would find a way to reuse the pattern in what they're doing. ;)

[Marlon Grech]

Well, the way I see it, developers can do a mess with whatever you throw at them :)

I would not see the Mediator fitting in other places more than the Controllers part.
The theory behind this is that, Views do not need such a system because Controllers will communicate and syncronize together and the View just need a relation with the controller. The model is just a dataservice and it will give you data for whatever you request. So if the controller is requesting the data, again the model does not need such a system.

But Controllers usually need to talk to each other and there is where the Mediator gets into the picture...

Sorry if I did not make it loud and clear at the begining but such concepts are quite hard to explain via email... I am sure that if it was a face to face conversation we would have came to a conclusion much easier ....

It was really nice talking with you guys... you're the best! One daya we must meet up for some beers :)

[Josh Smith]

Yes, beer is good.  :-D