I've just been reading Josh Smith's MVVM article and am working on a WPF application at the moment. I'm umming and ahing about transfering my work so far to MVVM but find the idea of working purely through databinding and ICommands without any UI event handlers, a little daunting in the sense that it could take a while to convert what I've done up to now.
I'm a self taught C#-er and I've yet to apply patterns such as this to my projects which have up to now just been using the code-behind model and separating out business logic and data access into separate assemblies.
I know that my code can get a little confused sometimes with regard to what belongs where so I was looking into patterns as a way to help me get things straight.
What other patterns might I look at? Any links to articles appreciated.
Some other presentation patterns that you may want to take a look at are Model View Presenter and Model View Controller.
Martin Fowler has a number of good articles on presentation patterns as does Jeremy Miller. Jeremy is coming out with a book on presentation patterns in the (hopefully) near future. Take a look at his wiki and Fowler's site.
http://martinfowler.com/eaaCatalog/
http://www.jeremydmiller.com/ppatterns/Default.aspx?Page=MainPage&AspxAutoDetectCookieSupport=1
My advice when adopting the MVVM pattern for WPF applications is to leverage off one of the existing toolkits such as MVVMLight by Laurent Bugnion. Once you get your head around messaging the loss of event driven code behind based logic seems plausible. It's still a little tedious in terms of LOB development if you're coming from an old-school forms over data background but once you are into the swing of it you will see the benefits and UI power that can be derived from bindings and value converters.
Related
I've surfed Wikipedia and have found such an article:
http://en.wikipedia.org/wiki/MVC4WPF
A part from the link upper:
MVC4WPF is an open-source, extensible, automated code pattern developed at Information Control Corporation for Windows Presentation Foundation (WPF) development based on the Model-View-Controller (MVC) and Presentation-Abstraction-Control (PAC) patterns...
I know, that WPF/Silverlight do use MVVM pattern: Model-View-ViewModel.
So is MVC4WPF a first version of MVVM?
I don't know the history of WPF/Silverlight development well, but MVVM has always remind me some sort of MVC.
And if it's true, then MVVM = MVC + PAC?
Whenever I see questions like this, I always think about Dr. WPF's design pattern.
It really doesn't matter what you want to call your separate concerns. You will hear a lot of WPF people talk about MVVM, but all it really boils down to is trying to keep your code separate. In MVVM, you have:
Model All your data classes. Knows nothing about anything.
View You gotta show your data. It knows about the Models, but not how to get them. "Knows" about the ViewModel through Bindings. Depending on how you wire them together, it may even create the ViewModel.
ViewModel This is the glue between the View and the Model. It can know about the View, or you can do your best to hide the view from the ViewModel.
In MVC you have:
Model All your data classes. Knows nothing about anything.
View You gotta show your data. Knows about Models, but not how to get them.
Controller This is the glue between the view and the model. It knows about the View and the Model.
Really, the last bit is all that changes (hence Dr. WPF's MV-poo). And in WPF, Bindings in XAML are so nice why would you want to write a bunch of code? Call it whatever you want, it is easier in WPF if the View knows a bit about the poo.
Having never used the PAC pattern, I can't speak to its strengths, but from Wikipedia, it seems to be very similar to MVC. So, I would classify it as a bit of MV-poo.
Now, considering that MVC4WPF hasn't had a release since 2009 (and their website with documentation is down as of 7/6/13), I would suggest you steer clear of it. I can't speak to its strengths or weaknesses, but if you'd like a good MVVM framework, MVVM Light and Caliburn.Micro both have good support and great reviews.
I'd also point out that not all applications need the poo. Mike Hillberg put this nicely.
I've been learning SL over the past month and have now shifted my focus toward UI Pattern Frameworks such as Caliburn.Micro and MVVM-Light.
I recently attended a session at a conference on Using the MVVM Pattern with WPF and SL. The presenter demonstrated using the pattern plain, without any UI Frameworks -- very simple and straight forward. In the presentation he recommended that we create a base VM to be able to use some common functionality (wasn't able to get more specifics due to time -- please feel free to clarify). Is this a reason why I would want to use a UI Pattern Framework?
My understanding is that UI Pattern Frameworks help implement patterns like MVVM by convention, thus allowing devs to not have to worry about that. Why else would I use a UI Pattern Framework?
Thanks in advance!
Rich,
For business app - your VM most likely going to need at least 2 interfaces:
INotifyPropertyChanged and INotifyDataErrorInfo
Like Kieren said - implementing INotifyPropertyChanged is very easy, couple lines of code. INotifyDataErrorInfo is little more but not bad.
MVVM Light is so "light" I'm not even sure what's is the point :) To me - someone who understands what MVVM about doesn't need this. You can look at it's source code to see what it does because most likely you will need to expand on that base class.
Caliburn, OTOH, is a convention-based framework which allows you bind without specifying "Bindings" and other magic like this. You need to decide if you really need it...
If you are working on something heavy, like LOB application with lot's of forms and stuff - I strongly suggest looking into PRISM. It's not an MVVM framework, it's framework to build complex composite UI. Learning curve will be steep, not like MVVMLight :) But it will cover most bases in your business application.
The only reason to use a UI Pattern Framework is if it provides the functionality you need or want.
If you only need to use INotifyPropertyChanged and maybe a quick RelayCommand, write them yourself (since it's ~5 lines of code, a couple of classes, ~30 lines in all).
If you need more, use one of the pre-built frameworks.
Does the code behind file have the same purpose as a Control class of MVC or the Boundary-Control-Entity Pattern?
I did some small projects with Silverlight and WPF, and most of the time I pretty much put the logic in the code behind file. Though with references to other classes. Not everything in the code behind.
What was/is the initial purpose of the code behind file and how do most of you use it?
Thanks,
Grant
The preferred design pattern for developing Silverlight applications is MVVM, in which the View Model is closer to taking over the role of a controller in MVC. When using the MVVM pattern, I'd only use the code behind of controls to implement UI-only (view-only) logic that has little to do with the data, such as performing animations and other special effects.
Originally, the code-behind file, in conjunction with data converters in WPF, served the same purpose as the code-behind in VB6, C#, VB.NET, what have you. It is primarily a place to put code that responds to UI events. However, in the case of WPF and Silverlight, coding in the code-behind file is potentially very messy and can easily lead to maintenance problems later on, if there is anything more than the simplest program to be implemented.
"Model-View-ViewModel" (MVVM) was conceived, I think, late in the development of WPF; Silverlight was conceived later than MVVM. Near as I can tell. Not every consultant I've heard talking about WPF or Silverlight is convinced that MVVM is "the preferred" design pattern, but it is a solid abstraction model.
WPF isn't as well tooled as WinForms, even today. This is part of what makes it potentially very messy with the potential maintenance problems. MVVM, as a design pattern, makes up for a lot of the drawbacks stemming from the immaturity of XAML and WPF/Silverlight as a user interface model, while bringing forward most of the tremendous advantages offered by XAML and WPF.
Summaries of MVVM are available here, here, and here. Josh Smith is a leading authority on the pattern, he sells a book called "Advanced MVVM" which I'm told is useful; I was able to implement some complex implementations without it, though.
What are the strengths and weaknesses of various MVVM frameworks for Silverlight?
I know similar questions have been asked before, but the field is moving quickly and the answers given are rapidly out of date.
I'm specifically looking for a brief assessment of the following frameworks -
Prism
Caliburn
Cinch
Goldlight
MFedMVVM
MVVM Light
nRoute
Structured MVVM
...plus any others that anyone is aware of.
The disadvantage of any framework is the same: It's someone else's code and it's someone else's implementation of the pattern. You're ceding control of the solution to someone else's code. If you're comfortable with that, by all means, go for it.
But MVVM is a really simple pattern to grasp. Implementing it is actually pretty trivial; WPF and Silverlight have baked in most of the core components you need to make binding work, and thus make MVVM work.
I've found that all I really need to do MVVM is an event aggregator for messaging across classes, a base view model class to handle the repetition of coding INotifyPropertyChanged, and then an IoC container for wiring up my dependencies. That's about it.
After my experience with the Component Application UI Block, I tend to shy away from anyone else's "framework". Especially if I can write the core bits myself in short order.
We do MVVM on our projects at my current job and my infrastructure is literally a couple of classes and interface for just what I stated above.
I cannot speak for the other frameworks listed but I can say that I've had great success with the MVVM Light Toolkit. I sympahize with the perspective that you can "roll your own" framework when you need it but MVVM Light is small and inobtrusive; it doesn't take over your application architecture but just provides a few basic necessities of MVVM:
RelayCommand - Command class that you can use for just about anything
Messaging - Ability to do messaging and message aggregation
ViewModelBase - Implements INotifyPropertyChanged etc...
ViewModelLocator - A straightforward utility for injecting ViewModels into Views.
I think the reaction to frameworks caused by something like the Component Application UI Block (and its Silverlight cousin, Prism) should be allayed by a framework as lightweight and straightforward as this one.
One challenge with Silverlight controls is that when properties are bound to code, they're no longer really editable in Blend. For example, if you've got a ListView that's populated from a data feed, there are no elements visible when you edit the control in Blend.
I've heard that the MVVM pattern, originated by the WPF development community, can also help with keeping Silverlight controls "blendable". I'm still wrapping my head around it, but here are some explanations:
http://www.nikhilk.net/Silverlight-ViewModel-Pattern.aspx
http://mark-dot-net.blogspot.com/2008/11/model-view-view-model-mvvm-in.html
http://www.ryankeeter.com/silverlight/silverlight-mvvm-pt-1-hello-world-style/
http://jonas.follesoe.no/YouCardRevisitedImplementingTheViewModelPattern.aspx
One potential downside is that the pattern requires additional classes, although not necessarily more code (as shown by the second link above). Thoughts?
I definitely think you should use the MVVM pattern for Silverlight applications - and one of the benefits of the pattern is that you can actually make your application really blendable through some simple techniques. I often refer to "blendability" as "design for designability" - that you use certain techniques to make sure your application looks great in Blend.
One of the techniques - like Torbjørn points out - is to use a dependency injection framework and supply different implementations of your external services depending on wether the code is being executed in Blend or in the Browser. So I configure my container to use a dummy data provider when the code is executing in Blend, and that way you get design time support for your list boxes, data grids etc.
The challenge is often how to set the DataContext declaratively - so I often end up using a service locator class a a "front end" to the IoC container. That way I can bind the data context to a property on the service locator.
Another technique is create some kind of ObjectDataSource control (non visual) that has two properties: Design Time DataContext and RunTime Data Context. The control does the job of detecting where is being executing, and then setting the Parent DataContext to the right object.
I'm not sure if I can answer your question, but I have foudn the article below very valuable. Jonas Follesø is using ninject to switch out his services when in design/blend mode. Very nice!
http://jonas.follesoe.no/YouCardRevisitedImplementingDependencyInjectionInSilverlight.aspx
I also agree with Jonas regarding MVVM with Silverlight. I do believe that MVP is also a good choice, but recently I have had time to try both MVP and MVVM with Silverlight and I am much happier with the results from MVVM. (Yep, I changed my mind the more I used MVVM). The VM abstracts the binding of the Model from the View (obviously) in MVVM which allows for more binding scenarios (at least cleaner ways to do them) than with MVP. That's just one aspect, though.
I'll be posting some examples of both MVP and MVVM with Silverlight on my site.
I've tried a few options and I'm settling on MVVM as the best choice for me. Blendability is an important point, and I also find the VM aspect intuitive for rigging up dynamic behaviors and procedural effects and animations (like Nikhil's Silverlight.FX). At one point I tried to avoid Blend altogether through fluent interfaces but am finding the coupling between UI and behavior too painful in the long-run. I want to design my UI in Blend and then add effects and other behaviors in code, this is proving to be the best pattern for me to follow so far.
I think many of us are waiting for the trailblazers to go ahead and create really good sample apps using MVVM in Silverlight (and WPF for that matter). There are a number of tricky areas such as the lack of ICommand in Silverlight, or the difficulty of interacting with animations starting and stopping only using data binding.
Its definitely a pattern to watch for the future though, and is worth trying out if you don't mind 'cheating' occasionally in the places where you can't quite figure it out.
I love the ViewModel pattern and highly recommend it. I have a couple of "getting started with ViewModel" types of posts on my blog.
ViewModel Pattern
HelloWorld.ViewModel
Binding Converts - VisibilityConverter
Silverlight Airlines with a ViewModel
I agree with Jonas. MVVM seems to be the model that works best for me (though John Papa thinks MVP makes more sense). I have an MSDN Article on this coming out in March that hopefully will answer the call for a good example.
BTW, I would like to see some cohesion in the MVVM Framework department. There isn't a good solution for a framework to follow yet. I like Jonas' (I think Jonas' is the FX Framework) but since its not WPF compatible it might not be the right choice for some.
I've been using MVVM lately on a couple of different Silverlight projects and it's been working really well, I would definitely recommend it. Jonas's post is a great place to start, I've recently blogged on my MVVM experiences too and created a really simple solution to demo the main touch points.
There's a very good Techdays 2010 video introduction to the MVVM pattern, clearly explained:
TechDays 2010: Understanding the Model-View-ViewModel pattern
Hanselminutes podcast by Laurent
For more complicated applications that require a higher degree of automated testing it definitely makes sense, and the move away from DependencyProperties to DataContext binding is a lot neater than it's ASP.NET counterpart.
The biggest challenge I've found with Silverlight is testing the actual UI (there's one commercial framework so far I think), and the huge tangle of event calls you get into when using WCF services (or the WebClient for that matter) with Silverlight.
I've always thought MVVM and PresntationModel http://martinfowler.com/eaaDev/PresentationModel.html are essentially the same thing. PresentationModel is a lot easier to say.
I've used it succesfully in java swing, windows forms, WPF and silverlight. If you think in terms of separation of concerns a Presentation Model makes a lot of sense. You have one class whose only concern is providing a Presentation friendly Model.It really doesn't matter what technology is used to show it on the screen. It might change some implementation details but splitting the concerns apart is a good idea no matter how you show the information.
Because of that separation you can easily write tests against your presentation model regardless of the view technology. So that's a plus.
With the Feb 2009 release of Prism v2 by P&P, even better support for MVVM now available for Silverlight and WPF. See microsoft.com/compositewpf for more details.
Take a look at my article about MVVM and Silverlight in real life projects and decide for yourself.
http://alexburtsev.wordpress.com/2011/03/05/mvvm-pattern-in-silverlight-and-wpf/