Why is there a difference in the way the Application object is created in WinForms and WPF?
-> In WinForms we never created the Application object. It was always available (I believe it was Singleton pattern). In WPF, although hidden in App.g.cs we need to instantiate one.
-> In WinForms it was a sealed class, but in WPF the way to go is to inherit it.
Is this done:
to be able to define the application in Xaml (App.xaml)
due to introduction xbap/navigation projects?
What benefits does it really provide?
I don't know that the design decision is entirely motivated by the desire to be able to define the Application object in XAML. But that's reason enough, it seems to me.
Related
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 think I have a pretty good understanding of the MVVM design model, however I have a quarm with it in regards to WPF, Command bindings and how we are meant to use them.
To bind commands to the XAML directly we are meant to implement the ICommand interface within the ViewModel. Now, the ICommand interface is part of the PresentationCore.DLL, which, correct me if im wrong is part of WPF not the base .NET framework.
Isnt the whole point of the ViewModel and Model that it should be totally UI independant? For example, if I implement ICommand in my ViewModel and use it as a data context in order to bind commands from the XAML, isnt my ViewModel then dependant on the WPF frame work (in particular the PresentationCore.Dll).
What I mean is, if I was to go and try to use my Models and ViewModels in lets say a Windows Forms environment, I would have to reference the PresentationCore.DLL even though I shouldnt need it because im using Windows Forms not the WPF framework.
This seems a bit odd to me, am I missing something here? Is there another way I should be doing it to keep my Model and ViewModel totally UI and UI Framework independant, but still be able to utilise the Command binding in XAML?
Thanks in advance!
I also had this kind of problem but not in wpf but in POCO classes. What i did was I created two partial classes in two different assemblies. Like you create one partial class which is not presentationcore.dll dependent in your VM project and create its partial class in another assembly(say WPFVM) which implements ICommand stuff. Now for Winforms stuff add only VM project reference to View project and for WPF stuff add references of both VM and WPFVM to the View project. I hope this will help.
The point of MVVM is to have the view just be a view, and nothing more. Putting ICommands into the view model helps this as it pulls the code away from the view. Where you will run into problems is if you have to access something on the view that is not a dependency property, which means you can not bind to it.
In my opinion MVVM is very popular with the WPF, Silverlight because it naturally fits into it. The data binding concept in the XAML allows the Views & ViewModels to be bridged using a single property which is the DataContext. As no longer your logic is tied to controls, you get better testability, design-code separation and maintainability. You may be able to implement the MVVM pattern in other places also, but in WPF and Silverlight, it fits so easily due to its data and command binding support. I have read somewhere that, Don't take patterns religiously. They were made to make your life simpler rather than giving you more problems while following it. For Winforms i think there are better patterns, If you are focusing in reusing the business logic, move them out of your ViewModels to seperate classes something like serviceproviders or serviceagents and share them between your Winforms and WPF apps.
This has changed in .NET 4.5 compare
.NET Framework 4.5
.NET Framework 4
Can nonvisual WinForms controls be used from WPF, as long as they are instantiated programmatically? I am comparing two sets of components that are only available for WinForms, yet we want to create WPF apps "going forward."
Yes. If you reference the the correct dll any object from any assembly and namespace can be used. The big question is whether that is the right thing to do.
It would help tremendously if you mentioned which two sets of components you are referencing as we may know of a WPF only solution, hence saving you from having to reference WinForms.
I am developing a little utility view that will be embedded in several of our apps. It will sit in a common library.
Should I expose this as a ViewModel along with a default View implementation, or would it be better as a UserControl with a fixed GUI?
It is pretty self contained and I doubt it will need to be reskinned, but doing it as a UserControl seems a bit overkill with having to set up a load of dependency properties.
A simple ViewModel seems more attractive to me but wondered if this was the normal way of sharing stuff?
EDIT:
It would also be nice if I could embed this in WinForms apps too. Is this possible with View/ViewModel?
Well, in the end I went with View/ViewModel. This keeps the separation nicely and is easily pluggable into existing MVVM projects.
It also works fine in WinForms, given that a View is just a UserControl with its DataContext set to some arbitrary object (the ViewModel).
The only slight issue I had was the fact that Application.Current is not set in a forms environment, so I had to store the GUI dispatcher reference so I could marshal gui updates to the proper thread in my ViewModel.
I have an existing WinForms application for which I'm now designing new bits in WPF. Things are going reasonably well and I have run into my first need for a dialog.
I'd like to do the dialog in WPF. It appears as though I'm going to need to do a UserControl for the actual content and then host that content via a WinForms form with an ElementHost (since UserControl has no ShowDialog() method).
And that's where my question is. How does that work? Best I can tell, the WPF UserControl doesn't even have a DialogResult property (which makes sense given that it has no ShowDialog() method) - it looks to me like I'd need a WPF Window control - and I don't think I can use that in this case.
Struggling with the basic flow and setup of things here. Can someone shine a light?
Is this even possible?
You can open a WPF window from a WinForms application.
Just create the window and call ShowDialog(). The CLR will load the WPF framework and open the window.
If you want your interop application to work mostly like a WinForms app, then the approach you describe works fine -- I've pretty much the same thing in my interop cases.
WPF supports MessageBoxes (albeit a slightly different version than WinForms), and you could put something together using WPF Windows (extending it by adding something similar to DialogResult). However, the provided WPF controls suggest that they're trying to change UX interactions to minimize dialogs, particularly modal ones.
To make your life easier though, I would create a WinForms Form/ElementHost subclass specifically for dealing w/hosting WPF content, and depending on how clean you like your "using" declarations, wrapping your own DialogResult-like enumeration so you don't have to include the System.Windows.Forms namespace which can make your WPF code-behinds more cumbersome.