Related
Not sure if this an appropriate forum for this, but I need some guidance from those who are further down the road than I am with WPF.
I've used Telerik Winform controls for a years and have mixed feelings about them. They look good, but they are deeply nested, have a steep learning curve, and sometimes don't perform the best. For example, just working with a RadWindow in the WPF designer, it's slow compared with native wpf controls.
I like Caliburn.Micro MVVM framework and MahApps metro styles, but to keep the same look and feel for a ribbon bar I'd need to use another third party tool (like Fluent) or just use the Microsoft Ribbon View control and figure out how to use templates and styles myself (or find an existing metro template for it).
I tried to combine Telerik and Caliburn but had trouble getting them to work. There is a Caliburn Telerik library but its based on Caliburn Micro 1.5.2 and I'm trying to use Caliburn.Micro 2.0.2. Problem is I always get an aero-looking full window title bar and frame wrapped around the Telerik styled window.
I just don't know enough about conventions and such to make it all work together. And frankly, not sure it's worth the trouble. I'm looking for a more streamlined approach that lessens my dependence on pricy and heavy third party controls.
So, I'm looking for guidance on whether I should use straight Telerik, straight caliburn or go through the work of trying to get them to work together.
What I would prefer is to use Caliburn as the mvvm framework with a layer of styling, like what MahhAps provides. And for those controls that aren't styled, like the Ribbon Bar, to either use Microsoft's ribbon bar and find templates and styles that would work or maybe a 3rd party control like Fluent. But would I be getting in over my head in trying to learn templates and styles?
Sorry for the ramble, but I'm frustrated and need some help in working through this. Thanks.
I found a great resource that maybe others new to WPF and struggling with similar questions would benefit from: MarkPad, a Code52 project on CodePlex.
It's written in WPF using Caliburn Micro MVVM framework (although it's version 1.5.2 rather than the current 2.0) and MahApps metro styles with some "roll your own" windows. It's a great looking app with the kind of simple menuing system I was looking for AND an MDI implementation. It's also a good example on how to organize a somewhat complex WPF application, something I was also unsure about.
It answers the question: Do I need to use Telerik? The answer is a definite NO. It's a great learning tool for me and maybe will be useful to others.
My company is starting a major greenfield development project using DevExpress WPF controls. I just read this critical review of their WPF controls:
[…] DevExpress developers completely misunderstood WPF when they developed their WPF controls. I really cannot impress upon you sufficiently well just how much of a displeasure it is using their controls. I feel absolutely terrible (almost guilty) about talking about a vendor with such negativity, but they have made a serious mistake in their WPF suite, it has been a singular source of the most abject frustration for me in about a decade of developing software.
Do you agree that DevExpress does not understand the WPF paradigm and will cause our developers grief during development and maintenance? Can you suggest an alternate vendor of WPF controls? I'm looking for a vendor with WPF controls that will enhance our application while fitting well with the WPF API, binding and MVVM.
The link (above) to the critical blog post is broken. The original author has stated:
I wrote the original article, and have decided to work with DevExpress in a private capacity after speaking with them so I have regrettably decided to remove the post. Regards, Ira
Abject frustration is EXACTLY what I experienced thanks to DevExpress. I lost hours of my life attempting to simply bind a combo box. The drop-down list at best would only display my ItemsSource class name multiple times. I even posted a StackOverflow question to figure out what I could possibly be doing wrong. Finally on a whim I tried removing this one line of xaml:
devx:ThemeManager.ThemeName="DeepBlue"
Suddenly my problem went away. It was caused by the Developer Express wpf theme DeepBlue. Discovering the problem was a tremendous relief. My company will now be using Telerik WPF controls. My colleagues are quite happy with DevExpress Asp.Net controls. It is only the WPF suite we are avoiding.
I would like to clarify our opinion on usage of our controls in applications built based on the MVVM pattern. At the moment, we are working on a series of examples which should clarify how our controls can be used under different popular MVVM based frameworks (like Prism, MVVM Light and so on). There are a couple of problems in our WPF controls regarding the MVVM pattern and we are trying to eliminate them. However, generally there are no showstoppers that can prevent a developer from using our controls in a MVVM application. Hopefully, our examples, posted on the DevExpress Web Site will convince you in this.
I do not agree completely with the assertion that DevX developers missed the mark on WPF. However, I will say that it appears they may have had a steep learning curve to overcome. Lets face it, WPF is massive. To master it, even out of the box, is a daunting task. I do agree that DevEx controls will not fit into a MVVM pattern, but they do sit quite nicely in a MVP pattern. "Can you suggest an alternate vendor of WPF controls?" No, but I will suggest that you study additional patterns if you are stuck with DevEx.
I have used Syncfusion, Ingragistics, Telerik as well as various smaller libraries and DevExpress is my platform of choice. I find them to be not only super supportive of WPF and MVVM but their tech support has been phenomenal. I actually was mid project in a multi-million dollar project using Syncfusion WPF and found so many bugs in the library that my customer was close to pulling the plug. I switched mid stream to DevEx and they save my bacon. Their controls always seem the most up to date and incorporating the latest trends. I wish they did more Xamarin stuff and some of the other things that Syncfusion does but I would rather have less stuff that actually works than a wide array of stuff that doesn't.
I am working on Silverlight 3.0 and currently using code-behind in my Views. I would like to implement the MV(VM) pattern into my project as the project is growing. I have seen some WPF projects where the code-behind has NO CODE except for the InitializeComponent method, which I believe is the right way to go and just looks clean. Is this possible in Silverlight 3.0, that is, no code-behind?
Can anyone point me to some good Silverlight (3.0) MV(VM) tutorials / articles?
Without using some additional framework, Silverlight 3 does not support what you saw in WPF. Specifically, full Commanding support. Silverlight 4 has included Commanding for Buttons, which is a start.
You can look into other frameworks that provides this feature set, like Prism. This will get you along the right path, but I'm sure there are other options.
You can follow the MVVM pattern for Silverlight 3 applications without using a framework. However, it is much easier to use one of the many MVVM frameworks out there. Here are a few good ones:
MVVM Light
MEF
Simple MVVM
I'd recommend not using Prism as it is more complicated than it needs to be.
Other options include things like MVVM Light, which is lighter weight alternative to Prism for things like handling events and commands, however Prism does have a lot of functionality (and the Prism 4 talk has that sounding like a good option when it gets released).
One good community site to check out is the Composite Development Patterns Community, which was newly started but has an excellent goal of collecting articles and other help for working with development patterns like MVVM.
Lastly, John Papa gives a great overview of MVVM, limited to links so head to Google and look up "John Papa MVVM". :)
One thing to consider though, resources for SL3 aren't going to be as valuable as those for SL4, which opens up additional options for framework based commanding (ICommand that greglev mentioned), although it isn't still the full command support from WPF.
Jesse Liberty has a good primer on MVVM also using Behaviors for wiring events.
Silverlight and MV(VM) Pattern - No Code-Behind - Is this possible?
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
UI Design Pattern for Windows Forms (like MVVM for WPF)
Should MVVM be used for WinForms? If so, what is the advantage over using MVP?
I think that there are two answers here... really just one answer to "Should I" and one answer to "Could I".
As far as "Could I", it is certainly possible. MVVM really just relies on a view that can bind to a view model. Since WinForms supports binding, this certainly is possible. You may need to write some code to make that binding more useful in an MVVM world, but it is (at least) theoretically possible. If it worked well, the benefits would be pretty great, IMO. You could make sure that your WinForms "View" had no UI behavior, except for creating the visual objects and binding them (in code, not declarative like in XAML). WinForms objects are very difficult to test, where ViewModels are very easy to test.
As far as your real question: "Should I", that becomes much more of a project-level decision. What are your goals? If you are looking to make some rather complex UI logic testable, then you might at least look into it. Fortunately, though, there are other patterns (Model-View-Presenter, for instance) that have more community backing that also has you write a testable "presenter" class. I find ViewModels significantly easier to write unit tests against compared to Presenters, but I think that is a personal preference.
Just as an aside, the MVVM pattern is mostly another name for the "Presenter Model" pattern. You might look to see if anyone is having success with the "Presenter Model" against WinForms UIs.
Good luck!
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.
MVVM Specifically fits the markup + code and lookless model in WPF and silverlight. I would not suggest it to a winforms app as I believe it would be an overkill. I do not see any benefit over MVP in a winforms app. However in WPF and silverlight it is always the preferred than MVP.
Read up on the web what MVVM is and why it came to be. That should clear it up further.
I don't believe MVVM can be done in winforms(at least not without a lot of hacking). MVVM separates the view(your form) from the viewmodel(your logic).
The reason it can be done in WPF is because WPF allows loosely coupling the view from the viewmodel via databinding in xaml. This allows the ViewModel from not knowing anything about the view and still being able to function. This is a good article on MVVM basics, I believe that it will clear up several questions.
MVVM was specifically created for WPF, in order to take advantage of WPF features like bindings and commands. Windows Forms doesn't have these features(*), so it doesn't really make sense to try to apply the MVVM pattern to a Windows Forms application... You should probably use MVC or MVP instead.
(*) It actually has some basic support for data binding, but not as powerful as in WPF...
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/