Hello Soapers,

As I continue to explore MVVM and the tools out there for it, I came across the MVVM Light Toolkit by Laurent Bugnion. I think there is a lot of functionality in this tool kit that could benefit the SoapBox Core Framework. What do you guys think?

Specifically, I'm looking at the Messenger class and the functionality it could provide to SoapBox Core. Such a messenger could be used to loosely couple the various MEF imports and allow them to cooperate without introducing any extra interfaces or dependencies. Do you think it is a generally good idea? If so, how do you guys see such a logical component being incorporated into the current SoapBox Core? If not, what issues do you foresee?

Thanks

asked 02 Sep '10, 20:54

KarlB's gravatar image

KarlB
576202136
accept rate: 0%

edited 02 Sep '10, 21:19

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦
696262833


I like the Messenger class. It's somewhat reminiscent of MailboxProcessors in F#, or Agents in Erlang. I really like the idea of having it maintain weak references - that solves one major concern I'm having with the application I'm currently writing on top of SoapBox Core. I had some services that were exposing an event that anyone could subscribe to, and anyone could fire off the event, to notify when some specific thing changed. Then I started to worry about references hanging around because of the event handlers.

I'll dig into this a bit more. I've certainly heard about MVVM Light numerous times. The license is compatible, so it's possible we could include it.

Thanks!

EDIT:

I took a look at MVVM Light some more. I really like the simplicity of it. I find the following are things that I would be interested in using:

  • RelayCommand and RelayCommandGeneric (I stayed away from these initially because Josh Smith hadn't released them under an LGPL-compatible license. In this form they're compatible.)
  • IMessenger and the Messaging framework
  • EventToCommand

Now, I have to ask a hard question here: is there any value to integrating this into SoapBox Core, or can you just include a reference to MVVM Light in your own project and use these useful tools? I think they're 100% compatible.

MVVM Light is all about tools for MVVM, and SoapBox Core is about extensibility within an MVVM environment.

link

answered 02 Sep '10, 21:10

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦
696262833
accept rate: 50%

edited 02 Sep '10, 21:37

Thanks for the quick response. I hope the licenses end-up working out. I have thought of two approaches for integrating the MVVM Tool Kit(MTK), anyone's input on the pros and cons of either of these would be very helpfull.

Approach 1:

hack into the MTK source code and export the Messenger class using MEF, then import it where ever needed. This seems to be the most direct approach

Approach 2:

Create a wrapper class for the MVVM light toolkit, then export that using MEF and import it where ever needed. This is similar to how the Avalon Docks library is used in SBC, right?

Any thoughts?

(02 Sep '10, 22:00) KarlB

Your Point: "MVVM Light is all about tools for MVVM, and SoapBox Core is about extensibility within an MVVM environment."

My Response: I agree that MTK is about tools for MVVM, and I think that the messenger class is a tool that can make SBC even better at extensibility within the MVVM environment. I think that an important problem that both you and I have been experiencing in using SBC is that there is currently no easy way to loosely couple the individual imports and I think MTK can help solve such problems(I say you and I becasue you mentioned your "references hanging around" issue in the original response to my question).

Allow me to give a small example of how I think a messenger service could be of assistance in SBC:

The HighScores module extends the PinballTable. When a game is over, the PinBallTable iterates through all of its m_gameOverCommands one by one and using the command patter - triggers each of the contained IExecutableCommands, including the one exported by the HighScores module.

The problem with this is that there is no common and easy way for new IExecutableCommand objects to register with the PinBallTable after composition has completed. Similarly, there is no easy and common way for the IExecutableCommand objects that are registered at composition time to unregister (neither when they are no longer interested in the message, nor when they get disposed). Furthermore, the coupling between the PinBallTable and the IExecutableCommand objects is not as weak as it could be, becasue the PinBallTable still knows how many "subscribers" it has and has to dirrectly interact with them in-order to trigger them, it even needs to know about the IExecutableCommand interface that they support.

A Messenger Service, integrated into SBC, would allow the IExecutableCommand to register and unregister themselves whenever they want by simply interacting with the messenger service (and not the PinBallTable directly). What's more, choosing to use the messenger instead of the command pattern allows for a more loosley coupled relationship because the PinBallTable would not have to hold its' own IExecutableCommand objects, nor would it need to interact with them directly.

I think that a messenger service in SBC - if implemented correctly - would introduce an application-level Service Oriented Architecture (SOA) amongst all of the parts. Such a design would be great. Amongst many other great adavntages, implementing a nice data access layer would become easy. All you would have to do is have your model classes send generic messages to the Messenger Service in the form of data requests, then use a call back method to get data back.

Your Question: "... is there any value to integrating this into SoapBox Core, or can you just include a reference to MVVM Light in your own project and use these useful tools?"

My Response: I agree that this is not a simple question. You may have asked yourself a similar question when you decided to integrate AvalonDocks into SoapBox core instead of simply adding referrences to it, right? In my mind, there is tremendous value in directly integrating this into SoapBox Core (SBC).

One thought is that by integrating MTK into SBC as a service in the core, MTK will become even easier to use. You could even create a mechanism in which the view models all hook-up their listeners to the messenger automatically once all imports have been satisfied.

What are your thoughts on anything I said above? I have actaully tried to switch the HighScores module from the command pattern to this messenger pattern, but was not imediately successfull. I think the singleton nature of the messenger class is causing me some problems. If you try it and have success, or have in-sight on how you would migrate from IExecutableCommand to the MTK messenger, I would be very interseted in hearing what you have to say. Maybe that would make another great codeprojects article?

I am sorry that this is such a long message, I just want to mention one more thing: If you decide this is a good idea and it should be integrated into SBC, then I think this link could be a great help http://msdn.microsoft.com/en-us/library/ff647328.aspx . It might also help me convince you that a Messenger Service is an important component of an extensible framework like SBC.

link

answered 02 Sep '10, 23:57

KarlB's gravatar image

KarlB
576202136
accept rate: 0%

edited 03 Sep '10, 00:01

I don't think the AvalonDock decision was exactly the same. I wanted to create an abstracted layout manager that someone could replace in the future with a different one. If you want your layout manager to use page navigation and lay your pads out in a circle, you could do that by writing your own layout manager service. Similarly with NLog, you can easily replace it with log4net. Rather, with MTK I don't see why you'd want to wrap it. I think you want to use the classes directly. Now, if I update the functionality of the core using MTK, then yes, it should be included in SBC.

(03 Sep '10, 05:43) Scott Whitlock ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×17
×2
×1
×1
×1
×1

Asked: 02 Sep '10, 20:54

Seen: 7,082 times

Last updated: 03 Sep '10, 05:43

powered by OSQA