I am using mvvm architecture view first approach in my project. I mean I have view-viewmodel binding defined in resource file.
But i'm unable to open multiple instances of same view...If I open the the new viewmodel will refer to the first view.
Try setting
x:Shared="false"
Read more here
WPF initializes data templates as singletons by default. You can override this behavior by using the x:Shared=false setting. Note: This works only with compiled resource files.
A more flexible option is to use an IoC Container for creating the associated View for a ViewModel. You might have a look at the WPF Application Framework (WAF) which shows how this works by using the Managed Extensibility Framework (MEF) as an IoC Container.
Related
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
I'm trying to work out the best way to couple my Views and ViewModels in MVVM and I've settled on the ViewModel-first approach using typed DataTemplates, as described in this article and in this answer. I'm using Prism and have multiple modules which have their own projects/class libraries.
My question is: Where should my DataTemplates live in my solution?
Should I put the DataTemplates in a Resource Dictionary which lives in the same project that has the types/ViewModels it renders?
Should I put the DataTemplates in a Resource Dictionary which lives in the project which has the application's MainWindow (i.e. Shell.xaml)?
Should these Resource Dictionaries then be added to App.Current.MainWindow.Resources.MergedDictionaries?
I hope this is enough information to describe what I'm trying to do.
Update: see comments of selected answer.
I'm sure that the best way here is to use Themes\Generic.xaml resources file. This is file (it should be exactly in folder Themes and has name exactly Generic.xaml) used by WPF/Silverlight themes engine and contains resources shared through whole application. You can also create separate file in folder Themes with name like Generic.DataTemplates.xaml and add link to it from Generic.xaml. Google knows a lot about generic.xaml or you can see more details in my answer here: WPF Prism - Where to put Resources?
Updated to explain more clear.
I will say if your DataTemplate is generic:
i.e You have a UserControl that binds to a ViewModel, and that ViewModel has BaseViewModel, which expose some sort of properties. Your DataTemplate is displaying those properties. So you can use this DataTemplate on every ViewModel that Implement the BaseViewModel.
Is better to put it in App.xaml, so you will able to pull it out with the Key and apply on different place in your project.
But if your DataTemplate is very specific,
i.e There is a UserControl that only binds on the specified property in that ViewModel and you know no other control will binds to that ViewModel, you will want to put into the same Xaml file's Resources or where you define your UserControl.
According to Microsofts App Studio the DataTemplates should live in a DataTemplates Subdirectory under the Views Directory. A Universal app has this directory for both the Windows UI as for the Windows Phone UI so its not in the Shared project because they are not the Same. Don't use the Converge PRISM architecture. Its completely wrong designed! That was not written with a Windows and a Windows Phone architecture in mind but like they call it Converged. It should have been completely redesigned like it works in Microsofts App Studio. Don't look for Dependency Injection its not in it and not needed. Most use Dependency Injection for stub or fake interfaces. The DataContext for design data works now so good with json data that a Dependency Injection component would be overkill.
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've just begun dabbling in putting together a set of controls as assemblies and I'm working on default styling. What I currently have is a UserControl in a project (thanks Reed!) and I'm able to bring that into another project via reference. I plan to add more controls over time to build something of an SDK.
I currently have some hooks that look for resources in the hosting application which either apply the resources to their respective properties, or style out the control via hard coded defaults.
Is it possible to set up resource dictionaries within the project containing the UserControls so they can use those references as the default, instead of hard coding? If so, how do I target them?
(I have a ResourceDictionary set up within the same project as the controls: Resources>Dictionaries>Colors.xaml)
Thanks in advance!
E
You should really look at creating custom templated controls in library rather than derivatives of UserControls. This will allow projects that reference your library to specify an alternative default style for you controls in the same way as we can for the controls in Microsofts own SDK.
The Creating a New Control by Creating a ControlTemplate topic on MSDN is good starter.
I think this is a better explanation, but i'm trying on a desktop application and i got the same problem.
XamlParseException: Failed to create a 'System.Type' from the text 'local:CustomerEntity'
If I'm undestanding correctly you want to create the file "generic.xaml" in the folder "Themes". However, I don't believe automatic styling works with UserControl only with Control. Generally if you trying to make a control that can be stylized and retemplated you want to inherit from Control and not UserControl.
I'm writing a prism application, I've just created my 1st module, fired it all up and amazingly - it works.
The application is going to grow soon(TM), and I'll be facing the need to host those modules in separate GUI elements.
What type of GUI elements would you recommend to host the modules?
Is it possible to data-bind a module to some control like a tab-control? How is it done?
Is there some kind of a dock manager (similiar to AvalonDock) for Silverlight?
Have you looked at StockTrader sample project provided with PRISM? It has in Shell.xaml AnimatedTabControl (inherited from TabControl) to which are bound modules: WatchModule (look at WatchListController.cs file) and PositionModule (look at PositionModule.cs file).
[Edit]
Take a look also at Prism Explorer sample project, which is using TabControl in Shell.
There IS dock manager, check silverlight toolkit ( it is installed with sl4 or you can take it here )
Also there is an example of binding controls to tab control tabs with MEF on channel 9