Best Practice MVVM ? RRS feed

  • General discussion

  • Hello World 

    I need to get best practice for MVVM pattern. How to Implement Model to Communicate with Service, How ViewModel Communicate with Model.

    currently i am using MVVM Pattern but i think i am not using it best way

    like in my Model i am following this approach http://www.silverlight.net/learn/advanced-techniques/the-mvvm-pattern/using-the-mvvm-pattern-in-silverlight-applications , but i want to know what is the significence of Model in this example, they are just using callback method we can do this in ViewModel as well.

    Please let me know the best way to impliment MVVM pattern so that Unit Test is Possible

    Wednesday, July 18, 2012 2:27 AM

All replies

  • Models are generaly storing data (or most often querying a distant server or dealing with local files).

    ViewModel should be able to do the same, but it is not their function. VM are done to persist a View state and to adapt the data coming from the differents models for the view.

    the view itself is just done for UI.

    Using MVVM clearly shows the need for a communication system. Models can send some signals when data are ready for example, or VM can send other signals to others VM to create a synch, etc..

    In these cases, you must use a Messenger. All MVVM framework are offering one, under this name or another. Messages are allowing for any communication within the software without breaking MVVM isolation principles.

    If you look at MVVM Light framework you'll find a Messenger class using exactly this job. EventAggregator in Jounce or other framework is just another name for the same service.

    Monday, July 23, 2012 12:17 AM
  • can you please send me demo project that follow the given approach...please

    Tuesday, July 24, 2012 4:43 AM
  • This is quite simple, all depends on the framework you're using and you did not say it...

    Each framework has its own way. For exemple MVVM Light use a Messenger class exposing a singleton you can use to send generic messages and to register/unregister receivers using lambda expression.

    With jounce, the EventAggregator is needing each receiving class to implement some IEventSink<T> interfaces.

    As you can see, there is no simple code sample, all depends on the framework you are using. If you're not using any framework I think it's time to choose one.


    Tuesday, July 24, 2012 11:02 AM
  • we are using SL 5 for our project 

    Thursday, July 26, 2012 12:35 AM
  • That's ok for SL 5, but which MVVM toolkit are you using ? Prism ? Caliburn ? MVVM Light ? Jounce ? Other ?

    Thursday, July 26, 2012 7:50 AM
  • Your ROI will be worse if you go MVVM route ... your simple question instigated a serious of additional questions (valid ones) ... this is a lot how MVVM works.  It requires A LOT of "well what do I need to use to support this pattern" in it's implementation (most developers I talked to can't really explain it well) and it generates significantly more code for very little payoff.  Yes I know MVVM is a pattern and not an implementation ... but everything has to have an implementation at some point as "patterns" don't magically make UI's appear.  Biggest problem is the implementation of MVVM pattern.

    I'm not sure about you, but the enterprise wide applications I code, my rule of thumb is ALWAYS "less code" - re-use doesn't mean it has to be MVVM.  

    But do a google search on "MVVM sucks" and you'll see many thousands of real world experiences and why MVVM just has NOT helped many a company with ROI.

    But here is a positive blog on MVVM ... but the sad reality it's a long read and typically when one has to put that much effort into "defending a pattern" it's obviously NOT the way to go.  


    This might point you in the right direction.  But be warned it has lots of "but why would you do it that way", "must be this way", "can't do that", MVVM gets to be a "religious" experience.

    But like I said, your ROI will suffer.  I've done two application, one using MVVM and one not using MVVM ... both applications (similar in complexity) have required the close to the same number of enhancements and bug fixes but actual amount of developer time spent on the MVVM based application is about 1.5X more ... many reasons for this including (like any religion) the "interpretation" of the pattern and how each developer working on the same project will have a different "interpretation".

    Some claim that MVVM wasn't forced on us, well yes and no ... it was definitely OVERSOLD as the MVVM pundits are discovering.  For me, it really didn't solve any problems that's what patterns and new technology should be doing ... solving real problems thru better technology, not telling us "we must code this way" ... and that's what it really boils down to.

    Best of luck with it.


    Thursday, July 26, 2012 1:16 PM
  • Some claim that MVVM wasn't forced on us, well yes and no ... it was definitely OVERSOLD as the MVVM pundits are discovering.  For me, it really didn't solve any problems that's what patterns and new technology should be doing ... solving real problems thru better technology, not telling us "we must code this way" ... and that's what it really boils down to.

    Well said Rob, I think you have hit the nail on the head!

    Thursday, July 26, 2012 1:57 PM
  • MVVM Light

    Friday, July 27, 2012 12:49 AM
  • Some dev says that Model , ViewModel and View all in Client Side some says that Model will be a Server side Library....

    Friday, July 27, 2012 2:06 AM
  • Hey Ravi,

    I hope this link may be helpful for You...






    Friday, July 27, 2012 2:10 AM
  • If you're using MVVM Light then you can use the Messenger class to send strongly typed notification from anywhere in your code.

    Any class can then register (always through Messenger) any lambda or methods to answer the message.

    That's the way parts can "speak each others" with MVVM.

    Using MVVM Light, and if your project is middle or little size, you can also try a trick : using the ViewModelLocator to get direct access to any ViewModel without sending messages. In some cases this can be simpler. But to respect MVVM the best is to create an interface for each VM and to expose these interface in the Locator instead of real class (default behavior). This can work if all VM can be created statically.

    If the app is using dynamic ViewModels this trick is not applicable.

    Of course, this can work without defining interfaces for each VM, but MVVM is broken. This can be perfectly acceptable if there is no plan for Unit Testing nor any dynamic View or ViewModel use or exchange at runtime.

    Most project are not using Unit Testing and in most projects no VM will be connected to new view without heavy modification. In these cases, the Locator trick is easier than using Messenger.

    Saturday, July 28, 2012 12:25 PM
  • MVVM gets to be a "religious" experience.

    I thing anything in programming can become a "religious" experience when it is applied by people that does not think by themselves.

    Any methodology, from RUP to Agile, any modeling system like UML, anything.

    MVVM does not escape the rule...

    A developer must first uses his brain before using already made methodologies.

    A pattern like MVVM is not done to avoid the developer using his brain. On the contrary, more sophisticated is the pattern, more the developer must be clever !

    MVVM is like object programming. I knew a few guys that was not able to reach the stage. Those people must not use object languages, nor MVVM or any other sophiticated programming methodology.

    Blaming the pattern is not a good approach. It is just hiding the truth, some people can't reach the stage.

    Applying recipes can seem to be the goal of a pattern. That's an illusion... And problems begin when someone is believing this illusion. The pattern / methodology is then applied like a "religion", with no knowledge, mechanically, like a rite.

    Here begin the problems...

    Applying a pattern when you have the requiered skills is never a problem.

    Saturday, July 28, 2012 12:38 PM