I just commented on your blog with 2 questions. Would love if you can reply there. In the mean time I will try that myself, thanks!!
found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.43/2043 - Release Date: 04/06/09 06:22:00
Just curious, did any of you guys try NInject or another Dependency Injection framework to solve this kind of issues? I know I promised I would write about it, and didn’t have time yet, but with NInject you get a central repository of objects, which provides an easy access to them. For example, if you create a MainViewModel and a SecondaryViewModel using NInject, you can then easily get the SecondaryViewModel from the MainViewModel and call methods on it directly.
NInject adds a little overhead to the application (especially in Silverlight where size matters), but offers the advantage of a well known, well tested framework to solve this kind of issues. In addition, it is very easy to create a design time view model vs a runtime view model, and to keep the design time implementation separate.
Just curious to hear your thoughts, and yes I will write about it, I promise J
Version: 8.0.238 / Virus Database: 270.11.43/2043 - Release Date: 04/06/09 18:59:00
I am currently writing a MSDN article on Prism (which uses Unity’s DI container, but you could use Ninject or other container) and it solves this issue with a typical IoC model but also for Silverlight allows you to specify modules in .xap files that can be downloaded behind the scenes or on demand. Prism encompasses other problems (I like the DelegateCommand<> and EventAggregator a lot too). In this way I think Prism solves a lot of problems for WPF, but the ondemand and componentization at the .xap level loading of silverlight projects make it a home run for Silverlight IMHO.
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Shawn Wildermuth
Sent: Tuesday, April 07, 2009 11:49 AM
Subject: [WPF Disciples] Re: New Mediator
I am currently writing a MSDN article on Prism (which uses Unity's DI
container, but you could use Ninject or other container) and it solves
this issue with a typical IoC model but also for Silverlight allows you
to specify modules in .xap files that can be downloaded behind the
scenes or on demand. Prism encompasses other problems (I like the
DelegateCommand<> and EventAggregator a lot too). In this way I think
Prism solves a lot of problems for WPF, but the ondemand and
componentization at the .xap level loading of silverlight projects make
it a home run for Silverlight IMHO.
Microsoft MVP (C#), MCSD.NET, Author and Speaker
The Silverlight Tour <http://www.silverlight-tour.com/> is coming to a
I don’t really prefer attribute-based approaches in general, I guess this is my alt.net hidden side speaking LOL. I am currently experimenting with a combination if interface/implementation based messages, and the WeakReference approach that Josh describes. Maybe it can provide an alternative.
Yes I see bit from all of us in there.
As Karl/KDAWG/Keith mentioned to me yesterday, this is the real power of the
Disciples. The fact that passionate people all over the world can easily
collaborate on projects like this is fantastic.. :)
No virus found in this incoming message.
Version: 8.0.238 / Virus Database: 270.11.44/2044 - Release Date: 04/06/09 18:59:00
Sorry I couldn’t get into this yesterday.
I’ll get my head around this tonight and see where I land.
Marlon great point about partial trust.
This is solvable.
hehe... I already have the code in my mind.... all I need is 5 minutes to write it :P haha....
but let's wait for the other Disciples to put their input....
P.S And yes mike it is do able.... I already did this in a sample app with a similar setup.... in the example I wrote the parameter is a constant which is the way you should define a Mediator message.
In Marlon's setup, the message IDs can be const strings exposed off some class. That should work ok.
Remember you can't use a parameter to an Attribute unless it's a compile time constant or an enum.
I like this....
I would do it a bit different.... (or the same as you are saying which would mean I didn't understand correctly, which is most likely the case here :) )
something like this
public void Test(object args )
the register would scan the VM and register all the methods to the messages. This way you only scan once.... what do you think? I think we are saying the same thing
I think it would be better to decorate the callback methods of the Colleagues with an attribute, and specify the message ID in the attribute's constructor. In your Mediator/WeakDelegate code, scan the Target object (i.e. Colleague) for a method decorated with your custom attribute, where the MessageID equals the message of interest. This is better than passing in the method name to the Mediator for the following reasons:
1) The method names on the Colleagues classes are not duplicated in the code. If you change the name of the callback, you don't have to remember to change the method name passed to the Mediator.
2) The Colleague class's are more self-documenting, because the callback methods are attributed with the Message ID that they are associated with.
3) The callback locating logic is simplified, because you don't have to worry about things like method overloads.
What do you think?
I got one implementation working, need to refine it, then I will blog about it. It is based on the following concepts:
IMessage<T>: this is an interface that defines the message to be broadcasted. It has one property of type T named Content
IMessageRecipient: This is the interface that all message recipients must implement. In a WPF application, the ViewModels will typically be IMessageRecipients. One method void ReceiveMessage<T>(IMessage<T> message);
Messenger: This is the mediator. It keeps a list of WeakReferences on IMessageRecipients. It has a method Register(IMessageRecipient recipient, Type messageType) for registration, and a method Broadcast<U, T>(U message) where U : IMessage<T> for broadcast
Then there is a list of messages, for example public class EditMessage : IMessage<CustomerViewModel>
This Edit message tells a VM that it should now set its DataContext to the Content (of type CustomerViewModel). In a typical LOB application, I have SaveMessage, EditMessage, LoadMessage, and we can even define a GenericMessage that looks like public class GenericMessage : IMessage<object>
I can easily unit test my mediator. The last thing which I am still not too happy about is the best way for the IMessageRecipient to get a reference on the mediator. For the moment I store one instance in the App resources, I could of course also use a Singleton. What is your suggestion?
The more implementations to
compare, the better. I am hoping that every Disciple who is interested in
this will blog their Mediator implementation, and then we can compare them all
to come up with the optimal design. And, as Bill pointed out, we should
also compare ours to the EventAggregator in Prism/CAL.
Yep, good thinking. Using the App store or a Singleton works fine too. I am implementing a LOB example based on my WCF service I demoed at MIX. It works really well so far.
No virus found in this incoming message..