What aspects and practices specific to WPF could be most useful (and not inconceivable to implement) in non-WPF GUI programming?
I was introduced to the command pattern by learning the WPF commands. It forms the basis for the UI - code separation, which I believe should be utilized in other applications.
Updating of the view via events. Databinding magic happens due to INotifyPropertyChanged and INotifyCollectionChanged. Writing a non-WPF app that, rather than blocking on queries, updated its data through either these interfaces or a custom one is a solid practice that can help ensure good separation of responsibilities as well as testability.
MVVM or Model-View-ViewModel is a fantastic design pattern and one that I hope will become widespread on the internet.
On that, have a look at Steve Sanderson's Knockout UI javascript library.
Ok, it's not entirely specific to WPF (it is used in silverlight as well), but I find IDataErrorInfo to be extremely useful outside of WPF / Silverlight. For my ASP.NET MVC applications my ViewModels implement IDataErrorInfo (for complex validations that are uncomfortable to solve using the validation attributes - such as if field A has a particular value, and field B has a particular value, then C can only be in a small subset of values). Then I have an extension method on my controllers that adds those data validation errors to the ModelState. Works like a charm.
Related
I'm currently searching what will be the Framework that we will use for our nexts applications. Currently we have applications running with winform and we plan to switch slowly to WPF(with new application, and then refactoring the GUI). We are a team of 9 people working this solution.
We have a big solution(currently, 300+ VS projects, ~1'500'000 line of code), so when choosing a framework, we are looking for something which will promote a clean code, a good infrastructure, but also a framework that will not slow(too much) the application.
Currently, I'm mainly interessted in Prism(which seems to be a little bit complex to fully understand) and Caliburn.Micro.
The Caliburn.Micro seems easier to use, but I'm a little worried that all those convention oriented stuff means that a lot of things will be done using Reflection on runtime.
Am I correct? Or is this something done at the compilation ?
Also I'm not sure I should consider MVVM Light, since it lacks of documentation/targeted application sizes.
First of all, Prism is not a MVVM framework. There is Prism.MVVM and it is a very lightweight MVVM library and it's independent of Prism.
Second, this <ListBox x:Name="Products" /> automatically databound to viewmodel should not be a performance problem in Caliburn.Micro, because plain Binding in WPF uses refelection anyway. Not sure if Caliburn uses reflection internally as well, but even if it does, it's hardly noticable at runtime if you dont do it in iterative scenario, e.g. inside ItemsScontrol with 1000+ items. If you experience preformance issues, nothing prevents you from writing it the standard way. However, the added value of this is questionable. IMO it brings more problems than it solves
If I may give you my advice, don't use any MVVM framework. All you need is INotifyPropertyChanged implementation and DelegateCommand (ICommand implementation). In some special cases you may need EventAggregator. Now tell me, are those three classes worth a framework? No, the aren't. Why introduce a dependency to a third party library?
If you are going to start such a large solution, the investment to write your own base class library is negligible. You can always take the source code of a class or two from Prism and use them in your own library.
The problem with those framework is that developers tend to over-engineer simple scenarios, such as using EventAggregator where plain event or even direct reference is more suitable. Or take Prism as an example, they use regions and view injection where simple ItemsControl could be used.
After 6 years experience with WPF I became a big proponent of ViewModel-First approach. MVVM then becomes much simpler. But most frameworks work better with View-First approach.
So, my vote is to not use any MVVM framework. If you have to use one, choose Prism.MVVM. And look at the source codes, they are well written.
I have used CM for a few years, start back when it was 1.1. I came over from PRISM. While I agree for some of the comments and points of view from other posters, you truly only option at this stage is to get the library/framework (which ever you choose to play with), wire it up and run with it a little bit in your off time from major projects. Implementing it on your "paid time" might be less than beneficial since you will undoubtedly have questions while "experimenting".
Experiment first then make your decision. Want separation of concerns? Want rapid development? Want to be able to drop a control on workspace name it and it will just work (assuming it has a built-in convention, or create your own convention for a 3rd party control), wire some viewmodel code up to a property or method that you named the control, then give Caliburn.Micro a try. Don't want to use Caliburn's conventions then don't. Just about everything for CM is modularized in to core needs with Nuget installs.
There are many MVVM frameworks as well as libraries all have different niche areas some are multi-platform, some are laser targeted on 1 platform. You can only use what you try and at the end of the day if you find something you like using and it works for you and your team, then it (framework/library) is the one that should be targeted.
Example of why I left PRISM
On the View
<Button x:Name="ClickMe" />
In the ViewModel
public void ClickMe()
{
}
public string FirstName
{
get{...}
set
{
_firstname = value;
NotifyOfPropertyChange();
NotifyOfPropertyChange( () => CanClickMe); )
}
public bool CanClickMe
{
get { return !string.IsEmptyOrNull(_firstname); }
}
Most WPF performance problems are not caused by the MVVM framework but how you implement your WPF application (e.g. are you using virtualized lists?). I think you should select your MVVM framework depending on your function needs (are all functionalities available, e.g. a command implementation, view model base class).
It is more important to define conventions and rules for implementing your MVVM/WPF and select the MVVM framework based on these rules. Some conventions and rules can be found in my article about recommendations and best practices for implementing MVVM and XAML/.NET applications.
There are lots of resources about choosing the right MVVM framework, for example:
What framework for MVVM should I use?
https://social.msdn.microsoft.com/Forums/vstudio/en-US/c8accd7e-69c1-48af-bf5a-4275910c2b9e/which-mvvm-framework-to-choose
I have a WPF GUI application based on MVVM design and data binding. Now, I want to reuse the core code (i.e. the data model) in a Windows service, or a console UI app, or a WinForms app.
Is such a design reasonable? If yes, what are the pitfalls?
Or should I make a standalone data model instead, and interface WPF via wrappers?
UPDATE:
Sorry, I should have been more precise. Let me clarify: I don't doubt the very modularity thing =) My concern boils down to having my current DataModel implement INotifyPropertyChanged, use DispatcherTimers, etc. -- all that non-GUI but still WPF stuff. The model's business logic is based on it.
Is this (non-GUI WPF) design acceptable for reuse in the aforementioned cases, or should I abstract further, until no references to WPF would be required at all?
Yes, this is perfectly acceptable and most of the time it is desired!
When you build an MVVM app, it should be in at least 3 formal layers:
Presentation WPF, UI, xaml, behaviors. All that stuff. Not reusable
Application The view models and structure that supports your application rules. All that stuff. Not intended for reuse
Foundation Database access, business objects. Domain specific algorithms. Ideally this bit should be reusable anywhere
The foundation layer is the clever bit. This is where the meat in your application sandwich is. It makes perfect sense for this to be totally agnostic of UI technology. WPF, winforms, ASP. It shouldn't even need a UI.
Edit for question update:
Removing all references to WPF is hard because sometimes you need a CollectionViewSource on your view models for grouping/filtering of results. That is a WPF class.
It is very tempting to view your seperation-of-concerns as 'just dont reference wpf' and that helps but it can make life difficult. Instead, try to be disciplined with the type of behaviors you are putting in. If you find yourself writing 'clever' (domain) code on a view model, shift it to the foundation layer as a business object method or extension. Similarly, if you find yourself implementing IValueConverter often, perhaps you should make better use of view models.
One thing is for sure, your foundation layer should never, ever, ever reference WPF.
Such a design is very reasonable! You can create a portable C# library for all .NET technologies including WPF, WinRT, ASP MVC, etc which can contain your models. Obviously you'll need to wrap these portable models into a viewmodel anyway, but IPropertyChanged is implemented in all XAML flavors.
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.
MVVM is most commonly used with WPF because it is perfectly suited for it. But what about Windows Forms? Is there an established and commonly used approach / design pattern like this for Windows Forms too? One that works explicitly well with Windows Forms? Is there a book or an article that describes this well? Maybe MVP or MVC based?
I have tried MVP and it seems to work great with windows forms too.
This book has an example of windows forms with MVP pattern (sample payroll application). The application is not that complex but will give you an idea about how to go about creating it.
Agile Principles, Patterns, and Practices in C#...
You can get the source code at
Source Code
EDIT:
There are two variations of the MVP pattern
(a) Passive view and (b) supervising controller
For complex databinding scenarios I prefer to go with the Supervising controller pattern.
In supervising controller pattern the databinding responsibility rest with the view. So,for treeview/datagrid this should be in the respective views, only view agnostic logic should moved on to the presenter.
I'll recommend having a look at the following MVP framework
MVC# - An MVP framework
Don't go by the name (it's an MVP framework).
Simple winforms MVP video
Winforms - MVP
An example of dealing with dropdown list
MVP - DropDownList
Simple treeview binding example (poor man's binding). You can add any treeview specific logic in BindTree().
Below is the code snippet.... not tested, directly keyed in from thought....
public interface IYourView
{
void BindTree(Model model);
}
public class YourView : System.Windows.Forms, IYourView
{
private Presenter presenter;
public YourView()
{
presenter = new YourPresenter(this);
}
public override OnLoad()
{
presenter.OnLoad();
}
public void BindTree(Model model)
{
// Binding logic goes here....
}
}
public class YourPresenter
{
private IYourView view;
public YourPresenter(IYourView view)
{
this.view = view;
}
public void OnLoad()
{
// Get data from service.... or whatever soruce
Model model = service.GetData(...);
view.BindTree(model);
}
}
As it has already said, i always worked in a MVP pattern when using Winforms. But the design pattern you will use not mean you will use right. There is loads of anti-pattern attached to MVP.
If you want to starts everything in a good manner, you have to use the framework for building smart client. So i will recommend to use that design and practices: Smart Client Software Factory http://www.codeplex.com/smartclient
You have a discussion here about the current smart client frameworks : http://codebetter.com/blogs/glenn.block/archive/2008/05/10/prism-cab-and-winforms-futures.aspx
PS: I like this post on the MVP anti-patterns: http://blog.mattwynne.net/2007/06/13/mvp-smells/
Hope this helps
The Model-View-ViewModel (MVVM) Pattern is a design pattern. Per definition a design pattern shows a common solution in the object-oriented world and this solution can be applied in various platforms (WPF, WinForms, Java Swing, etc.). I agree that MVVM is best used with WPF because it leverages the strong binding capabilities. However, Windows Forms supports data binding as well.
The WAF Windows Forms Adapter shows how to apply the MVVM Pattern in a Windows Forms application.
I have written about a variation of MVP/MVVM design patterns called MVP-VM, which is a tailor made solution for winforms applications that require full testing coverage and use data binding as main mechanism for keeping the presentation updated with model data.
MVVM for .NET Winforms
MVVM (Model View View Model)
introduces similar approach for
separating the presentation from the
data in an environment that empowers
data binding (WPF). Since .NET
framework 2.0 already offers advanced
data binding infrastructure that also
allows design time binding of
application objects - the ‘View Model’
entity can fit quite well in MVP based
environment.
I asked this same question to two of my techies co-workers: is MVVM for WindowsForms possible? Both gave me the exact same answer: "No way! WindowsForms is missing the rich bindings of WPF and Silverlight (OneTime, OneWay, TwoWay, OnewayToSource) and it is also missing the TypeConverters."
Screen Activator Pattern for WindowsForms - you can find it here, ported from Caliburn.Micro by jagui
Rich Bindings and TypeConverters - Truss by Kent Boogaart, does it in an UI independent way
Commands - WPF Application Framework (WAF) has a WafWinFormsAdapter project that takes care of some MVVM stuff namely commands
Again, can we have MVVM for WinForms?
Yes we can. We have all the pieces. We just have to glue them together.
I believe that MVP is a pattern well-suited to WinForms development - as is partly evidenced by it's use in CAB - Microsoft's framework for WinForms.
I use MVP in WinForms to extract code out of the View - because I can't test the View code. And also to enable code that needs to be reused (or is duplicated) to stay out of the View where it can't be shared.
I can refer to my own project where I use the MVP pattern ExceptionReporter.NET. Though I'm sure I don't use it perfectly.
You mentioned MVVM working for WPF - I think the reason for that is because of strong data-binding support. If you were not using data-binding in WPF (and it's certainly not compulsory) then you could choose MVP. The point being that MVP is a strong choice for any client-side application. And possibly a 'better' choice, even in WPF, if you plan on sharing code between projects that aren't WPF.
For more evidence of the value of using MVP in WinForms see Boodhoo's video presentation on using MVP:
http://www.bestechvideos.com/2008/06/29/dnrtv-show-14-jean-paul-boodhoo-on-model-view-presenter
And an MSDN article by the same author at http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
The BindTree method seems a little
flawed to me. Suddenly the the View
knows abou the Model. Is that a good
thing? There must be tons of poeple
being confronted with these kind of
problems. I am surprised that there
aren't any books about it. Since there
are books about everything in the .NET
world.
These Design not about hiding the model rather precisely defining the interactions between the different layers of the applications. You can change the backend completely and as long as you pass a Model through Bindtree your UI will continue to work.
Now class Model may be a poor choice of a name in the example that Rajesh gives. It can be TreeData, or RecordsData. However you define it, it has what you need to using the binding mechanism of Winforms to bind a specific control to the underlying data.
The best site to browse for this kind of material is here. Martin Fowler has collected a variety of useful UI design pattern and enterprise design patterns.
Again the key to this is the use of interfaces to precisely define how each layer interact with each other.
In my own application (a CAD/CAM applications used to run metal cutting machines) my structure looks like this.
Forms implementing form interfaces
UIDLL with views implementing view
interfaces that interact with forms
through the form interface. The
specific views register themselves
with UIViewDLL Views executes Command Objects found
in command libraries that interact
with the Model.
Command libraries; lists of
commands implementing ICommand.
The command that interact with
views do so through the interfaces
exposed in UIViewDLL.
UIViewDLL; exposes the View Interfaces
used by the commands.
Model; the classes and collection that
make up core data structures of my
application. For me these are things
like material, cuttingpaths, shape,
sheets, torches, etc.
Utility; a DLL that has commonly used
utility classes used by my company
that span different application. For
example complex math functions.
You can use Enterprise Architecture, Patterns and Practices as the starting point, although they are slightly dated.
Under General Guidance there is Application Architecture for .NET: Designing Applications and Services, which is a good introduction to .NET ways and layered N-tier application.
alt text http://i.msdn.microsoft.com/ms954595.f00aa01%28en-us%2CMSDN.10%29.gif
For more formal "patterns", there is Enterprise Solution Patterns Using Microsoft .NET.
(source: microsoft.com)
To name a few,
Model-View-Controller
Intercepting Filter
Three-Layered Services Application
The first good explanation of UI design patterns I read was in Jeremy Miller's blog - Building Your Own CAB. It describes the common patterns - Passive View, MVP, etc. and addresses some of the ways you might implement them in C#.
You can try MugenMvvmToolkit that allows to use a "pure MVVM" for WinForms.
Due to the fact that it supports bindings on all platforms, all of the native binding features available for WPF platform available on all platforms (include WinForms).
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/