I saw a lot of question on this topic and it took me some time to decide whether or not I would write another one ... but I think my question is a bit more complicated ... so here we go.
I'm currently working with a WPF application using MVVM.
The application is built with:
WPF
Prism V2
Ideablade (devforce) to access a database
Avalon dock for the docking feature
Telerik for the grid component
Views and ViewModel are generated with .tt file.
Views are generated in xaml (for WPF) files.
I know that:
Telerik has Silverlight controls
Using Prism V2 will probably help me doing a Silverlight version of the application
I don't know:
If the usage of devforce can be a show stopper
If the usage of avalon dock can be a show stopper
My question:
Appart from generating xaml for Silverlight ... where do I start ...
----EDIT----
Please, avoid any comments like "Silverlight will die" or "Silverlight xaml is a subset of WPF xaml".
It is a proof of concept and should be made using Silverlight. For the xaml, I can modify the application to use only simple ui element that can be both in Silverlight and WPF.
Depending on how you actually used Prism and other frameworks this can be a lot of work or quite easy.
I'd start at the 'bottom' because I'd expect the Models and ViewModels to be quite portable, at least that is what I have experienced so far. She fact that Silverlight more or less forces you to write async code everywhere might encourage you to investigate in (yet another) framework such as Rx
The Views could be quite a hassle; you will have to find controls that provide the same features that you are using in WPF, build them or invent something new. That can be a lot of work.
Another thing to consider is when your WPF app relies on many desktop features you might consider creating an Out of Browser Silverlight App.
As with any project try to find areas that will probably need a lot of attention and do those first; it's a waste of time to get a lot of stuff working to find out later that you will have to replace it because of an impossibility elsewhere.
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.
Is it possible to develop against Silverlight and WPF using the same source code? Maybe using some #define blocks where it is necessary.
Theoretically it should be doable. It's not a big problem for the code. However, you'll have to be very careful with XAML and use only the intersecting subset of WPF and SL (1), as there's no #if/#endif for XAML.
(1) Contrary to the common belief, SL is not a proper subset of WPF. It has some features that WPF does not have, though these are being worked on.
Incidentally, PRISM (the composite application block from patterns and practices) now supports Silverlight and there's a C9 video with a quick sample on using code in both WPF and Silverlight.
I think if you stick to MV-V-VM (or something along those lines) then a lot of your backend code will be reusable, but the XAML itself might need to be forked if you want a full on "rich" experience, unless you are willing to use the VSM beta for WPF.
I have no experience on that but I have used a component that targets both WPF and Silverlight environment with the same code (there are only few differences).
The component is Chart from Visifire and it's Open Source
Maybe you can take a look into it
You can use Visual Studio file linking to include classes from WPF projects in Silverlight - but only if they don't do any UI or XAML based stuff (as this is where you will usually find inconsistencies between the two)...
So keep it to business logic etc.
Flashcards.Show application is a great example of this WPF/SL/WP7 code sharing and cross platform possibilities.
http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/03/03/flashcards-show-planning-a-cross-platform-solution.aspx
Concept of cross platform is pretty simple because everything works on .NET and a similar XAML binding system. My advice here is to invest more time on architecture of the app in terms of MVVM and other abstraction to segregate the platform dependencies. So that a major percentage of the code can be re-used across while some of the XAML might need to rewrite depends on the visual complexity of the app in different platforms.
I also have a desktop application written in Windows Forms that is a middling size (a couple dozen major forms backed by 46 tables in the database). I'm thinking about rewriting the UI in WPF, but before I go there I was curious if there were any war stories about doing such a conversion.
I use LLBLGen to generate my low level data access objects, and I have a business logic layer above that. The forms are databound to the business logic objects, although the main form uses caching objects to minimize round trips on the more common navigation routes. The UI never speaks directly to the database: always through the UI -> business logic -> low level -> datastore path.
One control that I use heavily is the TreeView, which acts as a visual guide and short range navigation tool. The tree has been heavily customized with icons, highlight colors and it is the control I worry most about porting.
Is there a story that might convince me to go ahead and convert (or conversely, wait until Microsoft is closer to pulling the rug out from under Windows Forms)?
EDIT: I was asked in a comment what motivation for conversion I have. I have some concern about future proofing: I have 500,000 lines of code that were originally ASP and VBScript. We have been porting the functionality over time to ASP.NET and C#, but only as we make changes to the code. The upside is we have kept costs minimized, the downside is half the code remains ASP and VBScript. I'm concerned about a similar situation arising with Windows Forms applications.
Am I worried today about Windows Forms going away? Not even close to it... but the application is moving from ASP and VBScript to ASP.NET and C#, has nine years of history behind it, and probably won't be replaced this decade (instead, simply it will evolve). The desktop application is likewise a long term project with years of history.
For me, the WinForms vs. WPF decision is a simple one - if normal people are going to use it, the user interface can make the difference between a winner and a loser.
It is definitely a steep learning curve. But I have NEVER gotten done with a nice looking WPF application and said "Man, I should have used WinForms".
I'd say invest in the effort to make your UI better whenever possible for your customers, so yes to WPF if that's the case.
WPF has a ridiculously large learning curve. It will most likely require you to rewrite a lot more than you think for just changing the UI. Also, a lot of features that would make WPF nicer to use just aren't implemented or included in WPF yet. Unlike routeNpingme, I have written nice looking WPF applications and have said, "What a waste of time, I should have used Windows Forms and completed in 70% less time".
EDIT:
Also, unless Microsoft figures out a way to make WPF easier to learn, I don't see it catching on to the masses at all. WPF can do some very cool things, but a little effort to make it easy to understand instead of throwing stuff over the wall would have gone a long way. It would not surprise me in the slightest to see Microsoft drop WPF for something easier to work with in the not too distant future. So don't go changing your Windows Forms application just for the sake of changing it.
Pros:
Ridiculously easy data-binding (most of the time)
Ridiculously easy customization of look and feel
Cons:
Very steep learning curve
Some obvious bugs or issues. Similar to .NET 1.0 Windows Forms
Little or no tool support
In my opinion, WPF will definitely replace Windows Forms at some point. However, right now the tools are the main thing keeping it back. I disagree with Dunk that Microsoft will drop it for something else. Change it yes, but I think it's here to stay.
Should you change your application to use WPF now? No. Feel free to learn WPF but if your application works fine currently, then WPF won't give you anything extra. It just makes doing what is possible in Windows Forms much easier.
WPF is great. It is particularly good for extending controls like TreeView with customisations. You can add a string as an item in a TreeControl. You can also add a small panel containing an image and some text in various fonts and colours. Or you can add buttons, or anything you like. It has a completely general composability system. Same goes for ListBox, ComboBox, Button, etc. All their content or child items can be as simple as a string or as complex as a multipage document viewer with zoom buttons (if you want).
But the only way to find out is to try porting one of your forms. It shouldn't be too hard to make a WPF Window open from within your existing app. I started using WPF by making new GUI panels that were hosted inside a C++ Win32 application. Eventually it was so obvious that WPF was the way to go that we switched it around and made the outer shell WPF, with some ancient dialog boxes still implemented by the old C++ code where we couldn't be bothered to rewrite them (probably exactly what will happen with Visual Studio 2010).
Porting is a tough decision. So just some thoughts to help you decide.
WinForms is OK while you work by the rules and keep everything drawn as is. But even redrawing a border on some controls may require complex and precise work and skill, as you already know from tree customization. The same tasks can be done in a very elegant way in WPF.
Also, the data-binding in WPF saves me a lot of time. In the long term, you end up thinking about data-binding scenarios that could not be remotely possible in WinForms without special-case coding.
I do not even consider WinForms for new development -- there is no excuse for customization costs.
I have started introducing WPF elements within my WinForms application and so far have had a lot of success.
The application's main component is a grid control and I haven't yet found the text rendering of WPF sharp enough to present a table of important textual data.
But the application has several additional panels, and the majority of these are implemented using WPF. So, I'm going for a hybrid of WinForms and WPF via the ElementHost control.
I have found the flexibility of WPF to allow for a much more attractive and usable UI, and my users seem very happy with it. In my case, it's also been politically easier to introduce WPF one panel at a time.
WPF's main value to me is in the binding, not in the cooler UI. The worst WPF I've ever seen is when people use WPF just because it's newer, and put all the work in the code-behind, including not using binding. What you get is WinForms data management. So be sure you're going to use the wonderful binding when you do WPF.
I would port the OP's business logic to a business layer for ease of maintenance and conversion. I wouldn't port the WinForms to Xaml at all unless new Xaml functionality was needed, and preferably not until after the functionality was ported.
I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.