New Mediator
Marlon Grech
Today I had a few minutes to think about the "Memory Leak" in the Mediator implementation I did. I implemented a new version that solves this issue. I am not 100% happy since my solution uses Reflection (yes I love reflection and end up fitting it everywhere).
Basically the memory leak is solved by using a WeakReference and then using reflection to call a method on the WeakRefernce Target. This way GC can collect the ViewModel when it is not being used any more and the Mediator can check if the ViewModel is alive or not (and if not remove it from the InvocationList)
here is the WeakDelegate (Josh suggested this name I was gonna go for something crazy such as WeakCollogueInvoker :) lol haha)
class WeakDelegate : WeakReference
{
public string Method { get; private set; }
private MethodInfo methodInfo;
public WeakDelegate(object target, string method)
: base(target)
{
Method = method;
methodInfo = Target.GetType().GetMethod(Method, BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static);
if (methodInfo == null)
throw new InvalidOperationException(String.Format("Method {0} was not found on target object", Method));
}
public void Notify(object args)
{
if (IsAlive)
methodInfo.Invoke(Target, new[] { args });
}
}
... and here is how the Mediator does the invocation / cleanup
if (invocationList.ContainsKey(message))
{
for (int i = 0; i < invocationList[message].Count; i++)
{
var weakDelegate = invocationList[message][i];
if (weakDelegate.IsAlive)
weakDelegate.Notify(args);
else//remove the weak delegate from the invokation list
{
invocationList[message].RemoveAt(i);
i--;
}
}
}
... in Order to Register for a message from a VM you do the following
Mediator.Instance.Register(MediatorMessages.Message1, this, "Test");
anyway I attached a project that demos this... have a look and tell me what you think..... once we agree on this I will publish this as an update to my article....
P.S I am using strings not an enum. I do this becuase strings can be defined in other projects then the Mediator project.... I see a Mediator as a chat room.... A chat room does not know what messages are passing... the people chatting define those.... Mediator for me is similar
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
Marlon Grech
hihi :D
Josh Smith
Marlon Grech
Marlon Grech
public static void Test(object test)
{
MessageBox.Show("Message from mediator");
}
otherwise reflection would not get that method...
Josh Smith
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?
Josh
Marlon Grech
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
class MyVM
{
[MediatorNotification(MediatorMessages.Message1]
public void Test(object args )
{
....
}
public MyVM()
{
Mediator.Register(this);
}
}
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
Mike Brown
Mike Brown
Josh Smith
Josh Smith
Marlon Grech
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.
Marlon Grech
here is the new Register method
public void Register(object target)
{
foreach (var methodInfo in target.GetType().GetMethods(BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static))
foreach (RegisterMediatorMessageAttribute attribute in methodInfo.GetCustomAttributes(typeof(RegisterMediatorMessageAttribute), true))
invocationList.AddValue(attribute.Message, new WeakDelegate(target, methodInfo.Name));
}
... The Attribute
[AttributeUsage(AttributeTargets.Method)]
public class RegisterMediatorMessageAttribute : Attribute
{
public string Message { get; set; }
public RegisterMediatorMessageAttribute(string message)
{
Message = message;
}
}
... and now the cool part
How the VM uses this
class ColleagueA {
public ColleagueA()
{
Mediator.Instance.Register(this);
}
[RegisterMediatorMessage(MediatorMessages.Message1)]
public static void Test(object test)
{
MessageBox.Show("Message from mediator");
}
P.S in a real world application this Mediator.Instance.Register(this); will not be in every VM because it would be in the BaseViewModel (or at least i would put it there so that you don't have to call it every time)
Mike Brown
Marlon Grech
Mike Brown
Josh Smith
I set aside some time tonight to work on the Mediator problem. I refined Marlon's awesome solution, and removed the need for using reflection to locate the target method. I posted an entry on my blog, showing the prototype, and asked for suggestions/improvements/bugs/etc. If I get any good feedback on it, I'll send them your way.
Here's the blog post:
http://joshsmithonwpf.wordpress.com/2009/04/06/a-mediator-prototype-for-wpf-apps/
Josh
Sacha Barber
I like Joshes idea of attributes, let us know when we have some new code to look at.
Date: Mon, 6 Apr 2009 18:42:54 -0400
Subject: [WPF Disciples] Re: New Mediator
From: mbro...@gmail.com
To: wpf-di...@googlegroups.com
Get the New Internet Explore 8 Optimised for MSN. Download Now
Marlon Grech
here is the new Register method
public void Register(object target)
{
foreach (var methodInfo in target.GetType().GetMethods(
foreach (RegisterMediatorMessageAttribute attribute in methodInfo.GetCustomAttributes(typeof(RegisterMediatorMessageAttribute), true))
invocationList.AddValue(attribute.Message, new WeakDelegate(target, methodInfo.Name));
}
... The Attribute
[AttributeUsage(AttributeTargets.Method)]
public class RegisterMediatorMessageAttribute : Attribute
{
public string Message { get; set; }
public RegisterMediatorMessageAttribute(string message)
{
Message = message;
}
}
... and now the cool part
How the VM uses this
class ColleagueA {
public ColleagueA()
{
Mediator.Instance.Register(this);
}
[RegisterMediatorMessage(MediatorMessages.Message1)]
public static void Test(object test)
{
MessageBox.Show("Message from mediator");
}
Marlon Grech
Maybe I am missing something but your solution still would blow up in Partial trust... Delegate.CreateDelegate is still reflection at the end of the day no? (It still has CAS for ReflectionPermission)
![Laurent Bugnion, GalaSoft [MVP, MCP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUZ1C0QF1G84zUk-Bh1HAUf-2r0XJ2I0-e64mZ_kPpVPghO3A=s40-c)
Laurent Bugnion, GalaSoft [MVP, MCP]
Hey Josh,
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!!
Laurent
From:
wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On
Behalf Of Josh Smith
Sent: Tuesday, April 07, 2009 6:18 AM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: New Mediator
Hey all,
No virus
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
Laurent Bugnion, GalaSoft [MVP, MCP]
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
Laurent
Version: 8.0.238 / Virus Database: 270.11.43/2043 - Release Date: 04/06/09 18:59:00
Shawn Wildermuth
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.
Thanks,
Shawn Wildermuth
Microsoft MVP (C#), MCSD.NET, Author and Speaker
The Silverlight Tour is coming to a city near you!
Laurent Bugnion, GalaSoft [MVP, MCP]
Silverlight too.
-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
On Behalf Of Shawn Wildermuth
Sent: Tuesday, April 07, 2009 11:49 AM
To: wpf-di...@googlegroups.com
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.
Thanks,
Shawn Wildermuth
http://wildermuth.com <http://wildermuth.com/>
https://agilitrain.com <http://wildermuthconsulting.com/>
Microsoft MVP (C#), MCSD.NET, Author and Speaker
The Silverlight Tour <http://www.silverlight-tour.com/> is coming to a
Josh Smith
Josh
Marlon Grech
Josh Smith
Josh
Marlon Grech
Sacha Barber
Date: Tue, 7 Apr 2009 14:33:10 +0200
Subject: [WPF Disciples] Re: New Mediator
" Upgrade to Internet Explorer 8 Optimised for MSN. " Download Now
Josh Smith
Josh
Marlon Grech
Cool will stitch the code together and publish it :D
Josh Smith
Josh
Marlon Grech
Sacha Barber
GREAT
Date: Tue, 7 Apr 2009 08:43:40 -0400
Subject: [WPF Disciples] Re: New Mediator
Bill Kempf
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
Laurent Bugnion, GalaSoft [MVP, MCP]
Hey guys,
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.
Cheers,
Laurent
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Sacha Barber
Sent: Tuesday, April 07, 2009 2:50 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: New Mediator
Yes I see bit from all of us in there.
GREAT
Date: Tue, 7 Apr 2009 08:43:40 -0400
Subject: [WPF Disciples] Re: New Mediator
From: flappl...@gmail.com
To: wpf-di...@googlegroups.com
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.. :)
Josh
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.44/2044 - Release Date: 04/06/09 18:59:00
Mike Brown
Josh Smith
Josh
Josh Smith
Marlon Grech
Mike Brown
Marlon Grech
Mike Brown
Josh Smith
Karl Shifflett
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.
kdawg
Josh Smith
internal class WeakAction : WeakReference
{
readonly string _methodName;
internal WeakAction(Action<object> action)
: base(action.Target)
{
_methodName = action.Method.Name;
}
internal Action<object> CreateAction()
{
if (!base.IsAlive)
return null;
try
{
// Rehydrate into a real Action
// object, so that the method
// can be invoked on the target.
return Delegate.CreateDelegate(
typeof(Action<object>),
base.Target,
_methodName)
as Action<object>;
}
catch
{
return null;
}
}
}
Another point of discussion that we have yet to touch on is thread affinity and thread safety. In my implementation, Mediator derives from DependenyObject. This allows me to ensure that all messages are broadcast on the UI thread. This allows for the NotifyColleagues method to be implemented like this:
public void NotifyColleagues(object message, object parameter)
{
if (base.CheckAccess())
{
List<Action<object>> actions =
_messageToCallbacksMap.GetActions(message);
if (actions != null)
actions.ForEach(action => action(parameter));
}
else
{
base.Dispatcher.BeginInvoke((Action)delegate
{
this.NotifyColleagues(message, parameter);
},
DispatcherPriority.Send);
}
}
I'm not sure if this is a good idea or not. I assume that if this is being used in WPF apps (possibly SL apps too) then you'd want your ViewModels to be notified of messages on the UI thread, but am not convinced that this will always be the case. Also, if we are going to support sending out notifications from worker threads, the Mediator and associated types should take thread safety into account. What are your thoughts on this?
Josh
On Mon, Apr 6, 2009 at 10:53 PM, Marlon Grech <marlo...@gmail.com> wrote:
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.
On Mon, Apr 6, 2009 at 10:51 PM, Josh Smith <flappl...@gmail.com> wrote:
In Marlon's setup, the message IDs can be const strings exposed off some class. That should work ok.
On Mon, Apr 6, 2009 at 4:50 PM, Mike Brown <mbro...@gmail.com> wrote:
Remember you can't use a parameter to an Attribute unless it's a compile time constant or an enum.
On Mon, Apr 6, 2009 at 4:45 PM, Marlon Grech <marlo...@gmail.com> wrote:
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
class MyVM
{
[MediatorNotification(MediatorMessages.Message1]
public void Test(object args )
{
....
}
public MyVM()
{
Mediator.Register(this);
}
}
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
On Mon, Apr 6, 2009 at 10:35 PM, Josh Smith <flappl...@gmail.com> wrote:
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?
Josh
Marlon Grech
Basically the idea is, initialize the Mediator yourself (so no more singleton, that way as you Josh suggested you can have x number of Mediators) and pass the Dispatcher... If you don't then you have to ensure Thread affinity... What do you think?
Josh Smith
Marlon Grech
I will post the code to the group in 1 hour :)
then review and when we are happy we publish it.... Maybe you know what we should publish it via our blog :)
what do you think!
Laurent Bugnion, GalaSoft [MVP, MCP]
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?
Cheers,
Laurent
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: Tuesday, April 07, 2009 3:48 PM
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: New Mediator
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.
Josh
Josh Smith
Marlon Grech
Josh Smith
public DemoWindow()
{
InitializeComponent();
Mediator mediator = new Mediator();
this.stackPanelA.DataContext = new ObjectA(mediator);
this.stackPanelB.DataContext = new ObjectB(mediator);
}
This might be overly simplistic for many apps, but it's viable in some situations.
Josh
Josh Smith
Laurent Bugnion, GalaSoft [MVP, MCP]
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..
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.44/2044 - Release Date: 04/06/09 18:59:00
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.44/2044 - Release Date: 04/06/09
18:59:00
Josh Smith
Josh
Mike Brown
Pavan Podila
PITA, when I used it on a previous project.
On Apr 7, 10:13 am, Mike Brown <mbrow...@gmail.com> wrote:
> I think it does end up generating some "magic code" that is difficult to
> step into. I haven't really dug deeply into it myself beyond reading some of
> the introductory documentation. Also I can't imagine it'd be incredibly easy
> to unit test/mock out the implementations. I think I'll do a spike on a
> PostSharp driven mediator and report my results.
>
> > That sounds wickedly cool! Does doing this "IL weaving" result in code
> > that is difficult to debug in Visual Studio?
>
>
> >> I've been looking at AOP IL weaving frameworks lately. First there's
> >> PostSharp. Using postsharp attributes, you can create weave code into your
> >> application that wires your VMs to your mediator at compile time. That let's
> >> you avoid the performance hits and security limitations of reflection.
>
>
> >>> Marlon,
>
> >>> I've finally gotten the chance to look at your Mediator blog post. I was
> >>> correct... this is an alternate implementation of the EventAggregator in
> >>> Prism. Have you looked at it? There's always benefit in implementing
> >>> things yourself. At worst, you have a learning experience. At best, you
> >>> come up with a better solution. However, it's also useful in those
> >>> situations to look closely at existing solutions for inspiration.
> >>> Especially quality implementations, like Prism has.
>
Corrado Cavalli
Folks,
One day away from the list and nearly 70 messages!, I must admit that I’ve gone lost about the mediator thread and I have not seen latest release yet (link please?...)
Just one opinion: What I like in MVVM compared with Prism/Caliburn is simplicity, If I have to add IOC/PostSharp and other stuff to have it working, I agree with Shawn that probably it’s better to consider stable solutions like Prism/Caliburn.
What I really like about MVVM is that, starting from a simple ViewModelBase (similar at the one Kent’s just blogged about) and a bunch of RelayCommands I can do “almost” everything.
Mediator is of course the missing part to close the loop but it must remains as flexible (and easy to understand) as RelayCommand, so the lighter, the better (IMHO).
Speaking about mediator how do you suggest its use:
1-Mediator connects only Viewmodels associated to the same view.
2-Mediator is a singleton inside application and its shared among all viewmodels.
3-Each viewmodel in a view share a mediator and all views are coordinated by another “cross-view” mediator.
4-Other
Sorry if answer is already in available code, but as I’ve said, haven’t looked at it yet.
-Corrado
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: martedì 7 aprile 2009 20:14
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: New Mediator
I just checked out
EventAggregator, and must agree, that it is quite awesome. I think we're
wasting time working on a new Mediator implementation, before looking at
EA. It already does what we're doing, even has a WeakAction equivalent
known as DelegateReference. I can see the need perhaps for a lighter
version, like how my RelayCommand is a lighter version of DelegateCommand in
Prism.
Josh
Mike Brown
Laurent Bugnion, GalaSoft [MVP, MCP]
Hey Corrado,
I like # 2 (one mediator for the application) except that so far I didn’t implement it as a singleton, but I store one instance in the Application’s resources. Making a singleton forces me to implement the class this way, and I don’t want to have this restriction. Just I case, I want to be able to have multiple mediators in my application if needed (performances, etc…)
For example I could imagine having one mediator to let windows’ viewmodels communicate together (that one would be saved in the App resources) and then one “sub mediator” per window, saved in the Window’s resources, for communication between the user controls within the Window.
So far I got good results with the mediator implementation I am working on, I like its simplicity as you say. MVVM + RelayCommand + simple mediator, that really rocks. Super elegant solution.
Cheers,
Laurent
No virus found in this incoming message.
Corrado Cavalli
Hi Laurent,
Thanks for the explanation, I’ll have a look at your solution when ready.
Corrado
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Laurent Bugnion,
GalaSoft [MVP, MCP]
Sent: martedì 7 aprile 2009 22:10
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: New Mediator
Hey Corrado,
I like # 2 (one mediator for the application) except that so far I didn’t implement it as a singleton, but I store one instance in the Application’s resources. Making a singleton forces me to implement the class this way, and I don’t want to have this restriction. Just I case, I want to be able to have multiple mediators in my application if needed (performances, etc…)
For example I could imagine having one mediator to let windows’ viewmodels communicate together (that one would be saved in the App resources) and then one “sub mediator” per window, saved in the Window’s resources, for communication between the user controls within the Window.
So far I got good results with the mediator implementation I am working on, I like its simplicity as you say. MVVM + RelayCommand + simple mediator, that really rocks. Super elegant solution.
Cheers,
Laurent
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Corrado Cavalli
Sent: Tuesday, April 07, 2009 9:22 PM
No virus found in this incoming message.
Marlon Grech
The way I see it is that you are giving far too importance to the Mediator.... You shouldn't really care if there is 1 or 6 or 1000 mediator instances in your application (ok if there are a lot there will be a lot of memory usage for nothing :) ). All you care about is that you can publish a Message (with same arguments) and others can receive the message.... Think about this as if it was a chat room... If I want to send you a message I don't care if it is MSN, Gtalk or any other thing as long as the message gets through. The mediator is just a way how message between the ViewModels gets through. I think it's totally up to the developers need to constuct the Mediator as they want, Singelton, stored in App.Resources whatever. The mediator implementation should not specify how the Mediator should be created.... Obviously there must be some kind of guidance and that is why I implemented it as a Singleton the first time....
I am about to finish my latest implementation of the Mediator and post it over for you guys to see.... Yesterday I was about to finish it but I had to go out....
Corrado Cavalli
Agree, Singleton was just an example but exposing it from Application class might be a valid alternative.
I know that mediator is just a message dispatcher but I was just wondering whether a “single mediator” vs “group of mediators talking each other at higher level” would be a better approach from an architectural point of view.
-Corrado
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Marlon Grech
Sent: mercoledì 8 aprile 2009 08:58
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: New Mediator
Corrado,
The way I see it is that you are giving far too importance to the
Mediator.... You shouldn't really care if there is 1 or 6 or 1000
mediator instances in your application (ok if there are a lot there will be a
lot of memory usage for nothing :) ). All you care about is that you can
publish a Message (with same arguments) and others can receive the message....
Think about this as if it was a chat room... If I want to send you a message I
don't care if it is MSN, Gtalk or any other thing as long as the message gets
through. The mediator is just a way how message between the ViewModels gets
through. I think it's totally up to the developers need to constuct the
Mediator as they want, Singelton, stored in App.Resources whatever. The
mediator implementation should not specify how the Mediator should be
created.... Obviously there must be some kind of guidance and that is why I
implemented it as a Singleton the first time....
I am about to finish my latest implementation of the Mediator and post it over
for you guys to see.... Yesterday I was about to finish it but I had to go
out....
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
On Wed, Apr 8, 2009 at 6:20 AM, Corrado Cavalli <corrado...@gmail.com> wrote:
Laurent Bugnion, GalaSoft [MVP, MCP]
I agree. The implementation is not very important. I like mine (duh) because it is easy to extend and to test, but I will take any implementation if it works.
Marlon “had to go out” instead of programming WPF. Tst tst tst and so it starts…
.... in Order to Register for a message from a VM you do the following
Mediator.Instance.Register(MediatorMessages.Message1, this, "Test");
anyway I attached a project that demos this... have a look and tell me what you think..... once we agree on this I will publish this as an update to my article....
P.S I am using strings not an enum. I do this becuase strings can be defined in other projects then the Mediator project.... I see a Mediator as a chat room.... A chat room does not know what messages are passing... the people chatting define those.... Mediator for me is similar
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/
--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.11.44/2044 - Release Date: 04/06/09
18:59:00
Marlon Grech
Do you need to broadcast message through ALL the application? I always use the 1 Mediator because I think it is the safest... let me show you in C#
class ViewModel1
{
public ViewModel1()
{
Mediator1.Register("Message" x => Print(x); );
}
}
class ViewModel2
{
public void SendMessage()
{
Mediator2.Notify("Message", "Some data");
}
}
In this example the message that ViewModel2 is sending will never get to ViewModel1.... (because there is more than 1 Mediator).
I don't really see any benifit from having more than one Mediator.... I think it makes the whole thing more messier.... Just my opinion...
Marlon Grech
Laurent Bugnion, GalaSoft [MVP, MCP]
Dinner? Sissy ;) Real programmers use perfusions to get nutrients!
Laurent Bugnion, GalaSoft [MVP, MCP]
I changed my implementation to offer a DefaultInstance of the mediator and a set of static methods using this default instance. This way you can easily make sure that you are using the same instance throughout the application, but if you like you can create multiple instances.
Marlon Grech
Bill Kempf
Mike Brown
Pavan Podila
The nRoute link that Mike posted a few days back is pretty awesome. It has the notion of Mediator built right into it and a bunch of other concepts. I am actually thinking of giving it a try for my next project, including the concepts discussed in this post.
Wonder if others have looked at the nRoute library: http://www.orkpad.com/Blog/post/2009/04/02/Introducing-nRoute-an-application-flow-framework-for-Silverlight-and-WPF.aspx
Pavan Podila, MVP - Client App Dev
http://blog.pixelingene.com
------------------------------------------