A while ago, I posted a question regarding switching between a Blend-authored GUI and a Visual Studio-authored one. I got it to work okay by adding my Blend project to my VS2008 project and then changing the Startup Application and recompiling. This would result in two applications that had completely different GUIs, yet used the exact same ViewModel and Model code. I was pretty happy with that.
Now that I've learned about the Laurent Bugnion's MVVM Light Toolkit, I would really like to leverage his efforts to make this process of supporting multiple GUIs for the same backend code possible. The question is, does the toolkit facilate this, or am I stuck doing it my previous way?
I've watched his video from MIX10 and have read some of the articles about it online. However, I've yet to see something that indicates that there is a clean way to allow a user to either dynamically switch GUIs on the fly by loading a different DLL. There are MVVM templates for VS2008 and Blend 3, but am I supposed to create both types of projects for my application and then reference specific files from my VS2008 solution?
UPDATE
I re-read some information on Laurent's site, and seemed to have forgotten that the whole point of the template was to allow the same solution to be opened in VS2008 and Blend. So anyhow, with this new perspective it looks like the templates are actually intended to use a single GUI, most likely designed entirely in Blend (with the convenience of debugging through VS2008), and then be able to use two different ViewModels -- one for design-time, and one for runtime.
So it seems to me like the answer to my question is that I want to use a combination of my previous solution, along with the MVVM Light Toolkit. The former will allow me to make multiple, distinct GUIs around my core code, while the latter will make designing fancy GUIs in Blend easier with the usage of a design-time ViewModel. Can anyone comment on this?
I checked your previous question and this one, and I had never really heard about switching projects to work in Blend and in Studio, and end up with two different UIs. I think this was not the intent of MSFT when they built Blend. Instead, the possibility to open the exact same project and code files in both IDEs (and all the discussions I had with the various teams at MSFT) hints that the intent was in fact to have one application only which can be edited in both environments.
I think that in the end, the goal is to have a variety of tools that you can use to edit your UI - XAML, Visual Studio designer, Blend. Depending on your role in the project (developer, designer, integrator) and depending on your ability with the tools, you can choose one or the other.
This doesn't mean that we never switch templates! Depending on the kind of application (for example between a SL4 desktop application or a WinPhone7 application), we use the same ViewModel (and below) code, but slap a different UI altogether on the files. I demoed how to do that in this video:
http://channel9.msdn.com/posts/kreekman/TechDays-2010-Understanding-the-Model-View-ViewModel-pattern/
This is the same talk I gave at MIX but extended by 15 minutes where I show how to reuse the ViewModel and model files, but use a completely different UI for WinPhone7.
Another application is switching templates when a window is resized (used very often in WPF, but also applicable to Silverlight) in order to show less details or a different layout for different screen sizes.
I hope that this reply doesn't confuse you :) and in fact, I'd love to hear your comments on that before we continue the discussion.
Cheers,
Laurent
I think MEFedMVVM would be a good candidate for this. It is simple and you can combine it with other frameworks.
Related
When I first learned about Microsoft's then-new framework for developing desktop applications, WPF, I thought that one of the biggest benefits of it would be its efficiency. After all, I already know what the GUI controls and elements were that I wanted to use--I just have to slap them all on the page and then wire up all my bindings right, and I'll be done. After that, I learned about the MVVM pattern, which promised clean separation of concern within my WPF app.
I thought this was going to be great! I got into creating several different admin and data entry WPF apps with my team at work, and thus I began to crank out working software with robust but simple GUIs, right?
Not so fast, there, cowboy coder. My experience is that writing WPF is S-L-O-W.
Well, at least the way I do it. You see, after I have a picture of my GUI on a whiteboard, I code up the XAML with the controls that I want. This part, as expected, is fast--laying out the whole of a window is pretty quick. After that, its all the little stuff you want these elements to do takes awhile. I always seem to want to make this text bold in some cases; show a red error box in these other cases.
Then things unravel: this binding isn't working right over here--I have to write a converter and adjust the layout for the right values. Whoops, I forgot that extra NotifyPropertyChanged there. Oh, and I want to use a different template in this state vs. that, so I have to figure out what I can use to swap the templates in certain situation. This data is coming in asynchronously, so I need to make sure the right thing is happening on the right thread and that Property gets NotifyChanged as well. Crap, when I maximize my window, it doesn't stretch like I thought it would--must be because its container height isn't defined, but I don't want to define that, so I have to make it stretch in its parent. Oh, now I really want to make a user control out of this stuff over here, so I better implement some dependency properties...
On and on I go, spending hours and days on stuff that just feels so small and minor. I soon resort to cutting usability features and look-and-feel enhancements because this is taking just too darn long.
Does anyone have any tips or principles I need to try in order to write WPF efficiently?
A couple of things that have saved a lot of time for me:
Use DockPanel as your default panel for layout unless you have a good reason not to.
Keep a folder full of useful classes: a ViewModelBase class that implements INotifyPropertyChanged, a RelayCommand class, etc. There's no need to get fancy and try to make this a separate assembly that you build into your project; just write reasonably good implementations and copy/paste them into your new projects.
Get Resharper and use it. Use templates for creating dependency properties, properties that do change notification, and commands.
Find or build a good library for asynchronous task management.
I find that even for very simple applications I get more done faster with WPF than I did with Windows Forms. For applications that aren't very simple, there's absolutely no comparison.
For the most part, WPF applications are a lot of work to develop because it's harder to make the case for cutting out UI features. You can't just say, "Oh, that's not possible," because it probably is possible (whatever "it" is).
Write your own library, or find an existing one.
WPF is great, but out of the box it is missing some things that would make coding faster. I got tired of writing the same things repeatedly, so I ended up creating my own library full of things like converters, visual tree helpers, attached properties, custom controls, etc., and since then, my development time has sped up considerably.
In addition to my own library, I've also started using Microsoft's Prism and Galasoft's MVVM Light Toolkit. Both contain useful objects that I use all the time and are better than what I could code on my own. (Most used are NotificationObject from Prism, RelayCommand from MVVM Light Toolkit, and EventAggregator or Messenger from either one depending on the project, etc.)
Another thing I've done to speed up coding time is to take advantage of Visual Studio's macros. For example, to create a property with Change notification, I write the private property, hit Ctrl+E, Ctrl+R which generates the public version, then run a macro which automatically sets up the PropertyChanged notification in the setter method.
I almost never change the setter methods from the default macro'd one, and instead use the PropertyChanged event to handle any changes that should occur on the setter. This not only makes it easier to track application flow, but also greatly reduces the time I used to waste browsing through my public properties to alter a setter method.
I believe the right answer isn't for WPF at all, but it can fit what you're looking for.
Most of the times, when you want to leverage a new technology there's a time while you're not efficient, productive and your solutions aren't that impressive, innovative or just doesn't look like others.
What will give you more efficiency is working with WPF itself.
It's more about project management topics than programming. After finishing some project, your team and you should go to some room and discuss:
Success stories.
Problems during development.
Pros and cons.
Fails in the application architecture.
Communication problems within the team and customer.
... and so on.
If everyone shares their knowledge, project manager or team leader does a good job documenting each project story, finally everyone will have a "know-how".
In addition, it's important that you won't need to reinvent the wheel for every new project: if some pattern worked fine, do the same way next time, even if it's not the best way of doing it. And try to enhance it, if possible.
Design patterns, technologies, paradigms, languages, companies, colleagues and nothing are a silver bullet: Microsoft said WPF is a step-forward in Windows client developments, and it is that: a more modern approach to provide shinny user interfaces and a programming paradigm that fits nowadays' desired approaches, easing the relation between coders and designers, as WPF has XAML, which allows not only separation of concerns, but separation of professionals by area (designers, UI programmers, business programmers, ...).
Finally, as I said above, WPF won't be your silver bullet: learn from your own success and read a lot, see sample applications, download open source solutions, listen your colleagues, drink a coffee and, after all, after some headaches, some day in the near future, you'll leverage these technologies (and many others).
EDIT
I'd like to add that a good way of using the know-how is creating a Visual Studio guidance pack, so you can automate a lot of tasks like creating managers, views, models and other things just in the way your team would do by hand.
For example, you can create a guidance pack for a WPF CRM-like application and you can automate module creation. When you want to add a new module, guidance pack starts a process which adds all the necessary classes to start development this new module, and it can create a sample form already associated with a navigation manager, controller or whatever (it's just an example).
Guidance pack and T4 would be both good tools for automating tedious or repetitive tasks in everyday's tasks:
http://msdn.microsoft.com/en-us/library/ff631854.aspx
http://msdn.microsoft.com/en-us/library/bb126445.aspx
I have been using WPF since 2008 and can honestly say to do it right and clean does take more time than the same thing in WinForms would take to develop. I have written a lot more WPF than Winforms. That being said - if I need a simple internal utility - it is ALWAYS Winforms. If I have something forward facing to a client - it is always WPF. Why? Winforms are cheap and dirty and you get a lot for free. What you don't get is the fit and polish that WPF can provide. The flexibility with WPF does come at a cost - but in the longer run it's worth it for public facing software.
Yes WPF is a hurdle but it also has rewards. You are on the right track with a design pattern such as MVVM. Sounds like you have not even gotten to the "rewards" of dependency properties or event bubbling. But the control over the UI is great. Almost everything is a content control. In forms I was always writing custom controls to get the UI I wanted. In WFP I have never had to write a custom control for UI and doubt I ever will. The syntax is new but it is compact - I rewrote a Form app in WPF and the WPF has 1/3 the lines and more features. Read a whole book on WPF just to get grounded - I like PRO WPF in C# 2010. You could also say LINQ is complex but man does it do a lot in just a few key strokes. WPF is not something you just pick up on the fly as you next application.
we want to develop a silver light application. I am the programmer. management want to improve the Userinterface, so they want a web designer join the development. I am using VS2010 to develop the application. I know there is a tool callled expression blend, which is for designer. how can we work together. What is the best practice with this team of two of us.
Thanks.
David
We have hired an outside design agency to help with the design for a large Silverlight LOB application. I would suggest that you start the process with paper and pencil, gather ideas, look & feel, etc. Also consider who your target audience is, we created Personas that represent specific types of user, if your users have an issue with the final UI/UX thats bad.
We then let the designer create parts of the UI in blend with nothing behind (or maybe a little just to test an idea or prove a point).
At the same time you can consider/design the overall flow of the application (screens/views/sub-views) and get your infrastructure running (ie. which MVVM approach you like, how to chop up the views with controls or usercontrols etc).
Bringing the visuals together with the code we then did at intervals. It proved to be an iterative process but having different perspectives as the project progressed helped smooth out issues as they presented.
Definitely talk through the process before starting.
Bit of a ramble but I hope this helps.
I don't know about best practices for your situation, but Expression Blend can open the same project and solution files as Visual Studio, so you can both work from the same codebase. Whether you'll be stepping on each others' toes or not is another story. Perhaps somebody else will have more of an idea as to how the developer/designer dynamic works when working with Silverlight apps.
I would start with understanding of MVVM pattern.
With MVVM pattern you can create two separate ViewModels for every View. One can be a real one with good functionality and the second one will be for the designer - to work with fake data in Blend. Then you can easily work on the functionality side of the application (ViewMode and Model) and the designer will tweak the GUI (View).
You can test in ServiceLocator if you're in Blend or in runtime and provide appropriate ViewModel.
One of the easiest (and good for working in Bled) MVVM framework is: MVVM Light Toolkit
i've been learning wpf for about a week now..
and i have a basic question:
From a business view and development view (out of your experience).. what can and what cant be done with wpf(capabilities) ..
please try to be illustrative..
examples of undesired answers:
"Fully functioning stand alone applications with alot of animation and Glittering images"
A second question:
if i build a XBAP UI for my application, can i make the UI "not show" in a browser!
if u r going to answer from tutorials/websites/books.. please dont copy paste them directly, try to write it in your own words...
You can host anything built to the Win32 GDI/USER API (WinForms, ActiveX controls) inside a WPF application, so even if you hit some limitation with an app that is mostly WPF, you can always host some old controls inside it.
And since 3.5 SP1 you can even host animated DirectX graphics pretty seamlessly as well (although WPF's 3D support provides its own much simpler ways of achieving the most commonly done things).
As for comparison, the major advantage of WPF over WinForms is the way it keeps closely to its own component-based model, so a very large proportion of controls are able to act as containers for other controls. Want to put a combo box in a menu item? Not sure why you would, but you can. More usefully, you can put a button in a list box (or tree view). These kinds of thing are not possible unless you implement every standard control from the ground up (which is what WPF does).
The disadvantages are probably temporary: it can be a little unstable on some machines (the rendering code seems vunerable to display driver incompatibility) but this gets better with each service pack. Also the text rendering has been heavily criticised - it goes a bit further with ClearType anti-aliasing than Windows normally does, so some people complain that it looks blurry.
(The reason these are likely to be temporary issues is that Microsoft's Visual Studio 2010 is adopting WPF. So they are now "eating their own dogfood".)
You can pretty much do anything in WPF that you'd need from a GUI app. But that's not the real benefit, IMHO.
One of the real benefits of WPF is development speed and simplicity, once you get past the learning curve (and there is a learning curve!)
The other major benefit, and probably the biggest one, is that it allows designers to work on the presentation, do lots of interactive things, all using a designer-friendly (friendlier, anyway) tool and not having to submit requests to the coders. Just by changing the .xaml, a designer can make an application look almost completely different, and add all kinds of behaviors (panels disappearing, expanding, all kinds of neat stuff). Without changing a line of code.
You can in theory do anything in WPF what you want. Compare it with a WinForms application. Is there anything that you can't build with that? Not really. The same goes for WPF. It's just that WPF is better suited for some things, like animations, video, graphics, etcetera. As it is xaml based, it is also better suited for databinding against XML for example.
See also this related question.
As for your second question, I'm not sure what you mean by that. Do you mean if you can show websites using WPF? Yes of course, just like WinForms.
Oh, in WPF some things are still not implemented. DataGridViews as popular example are only in the codeplex preview. YOu have alot of things like theExpander which work in a differnet way, and you can have a lot of problems with autosized content.
I've been doing WPF applications with the MVVM pattern using Visual Studio, coding C# and XAML mostly by hand.
Now I've gotten up to speed with Expression Blend so that I can click together WPF applications quickly just using the GUI, which is very nice, much more control of the layout than fiddling around with all the XAML elements 80% of your time.
But it seems that my applications in Expression Blend are simpler and necessarily coupled, using events that are handled in the code behind, etc.
I find it hard to imagine how I would go from this simpler approach of Expression Blend to a decoupled MVVM application with Views, ViewModels, routed events and commands, etc. other than to just take my whole project into Visual Studio and rearrange it to the point that I couldn't really edit it visually anymore in Blend, but would be back to using Blend to create little pieces of XAML that I paste into Visual Studio.
For those of you who are working with more complex applications with Expression Blend, what are your strategies for keeping your projects decoupled in an MVVM way, yet at the same time structured "in the Expression Blend way" (where you can still see and edit whole parts of your application in a way that makes sense visually) so that you can continue to edit them in the Blend GUI as they scale?
I've been using Blend first and foremost as a rapid-prototyping tool. For this purpose, I really like it. In particular, I find it very helpful when I'm not sure how to set things up to get the layout/behavior that I want.
I rarely edit my main project files directly in Blend. I find it creates markup that is unnecessarily complex or verbose. Also, as I become more familiar with WPF/XAML, I find myself using Blend less and less.
I have been using Blend for the UI of my projects since version 1. Being that my goal is to fully integrate the designer to the project, I have plowed through whatever gets in the way of this goal. While not being aware of MVVM for some time now, I naturally arrived at the same conclusion, and have been making ViewModels without knowing there was a pattern for them. Now with the help of others that are working towards MVVM, it's getting better all the time. I have now developed 3 applications with rich UI and functionality where all the UI was done in Blend.
Read Josh Smith's MSDN article, look at Jason Dolinger's work, and Karl Shifflett's work to mention just a few.
Look closely at using ICommand, INotifyPropertyChanged, the ObservableCollections.
Also, look for how you can manipulate controls from your ViewModel. As an example, there is ICollectionView. Assume that you have a list of animals, and you have a set of types that you want to filter them by (birds, mammals, etc.)
By using ICommand and ICollectionView, you could expose enough control where a designer could construct a listbox to show the animals, and a menu to show the filter list. There is enough functionality in ICollectionView to know what the current selection is, and if you had ICommand-based commands for "SortByBird", "SortByMammal", etc then when the designer made the menu, it (assuming the window's context was your ViewModel for this window) would supply the designer with the proper options to bind to.
I am currently working with another team at my company explaining how my projects have been set up, and they are responding positively to the new role of the designer using Blend.
I have not been able to successfully use Blend end to end for that.
I find in the general case, it's faster to edit xaml by hand in VS (exception would include anything with non-standard brushes for example). Blend is very click-happy, and it's not really fast to top it off.
Another area where Blend is really useful is creating styles/templates from existing controls.
Other than that, I'm not sold yet. Its capabilities drop when using code-instantiated datacontexts so it's no help there, and it tends to generate useless markup, static sizes and such, which I really don't like.
Blend is great for giving you an idea about how things can be done, but the xaml it makes is terrible and tightly coupled. As you learn the xaml side of things better you'll find it's much faster to just write the xaml than use Blend. Until you get to that point you can make your changes in Blend but then you should refactor the xaml it creates to make it less tightly coupled and take out the extraneous UI elements.
I'm a little late to this party, but hope that someone can still respond. I've yet to find a search result that outlines the process for drawing a line between the designer and programmer. The first part of it is MVVM so there isn't any coupling between the GUI and the underlying "business logic", and I'm working hard on learning that right now. The other part that I haven't seen anyone write about is, how do you actually go about designing a project in Blend so that the developer can basically give you a GUI DLL of sorts, and then your application's GUI magically changes?
Here's what I'm looking for -- the developer writes his code as usual, and also writes a very basic GUI that proves everything works as expected. Meanwhile, the designer is creating his cool little GUI with all of the usability features people have come to expect. Now, the developer can run his application with his GUI, but then can also switch to the designer's GUI on the fly.
I guess if it can't be done on the fly, does that mean in the ideal case that the developer would have his VS solution include the XAML from the Blend solution? Then in App.xaml just reference a different start file?
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.