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.
Related
I just started looking into WPF and MVVM-Light a couple of days ago. At first I created a single windows desktop app and now I want to create a desktop app with several pages.
I read this tutorial and I think I understand the concept.
But I have one question. MVVM-Light uses the ViewModelLocator to avoid having a strong link between the view and the viewmodel. But does using a DataTemplate in the MainWindow.xaml (to associate view and viewModel) not go against this principle? Is this the right way to do it?
Lots of people use the DataTemplate method,that's fine. The other widely used method, setting DataContext to your ViewModel in code-behind, also creates a "link" between them. If there is no link, nothing would ever work at all.
I'm a complete n00b to WPF but I'm working on my first application. I already realize that styles I use in the application I will likely want to use in future applications, so I'd like to use some method of applying global styles from project to project.
I've seen plenty of tutorials on creating a control library project, but they all go into creating custom controls. I don't really need custom controls (yet) per se, just the standard Windows controls with custom styles.
I'm also a little unclear on the whole ResourceDictionary thing. I've found examples on creating one for an application project, but not so much for a control library project.
What I'm looking for here is a) is a control library really what I need or am I creating more work than necessary? b) am I on the right path with a ResourceDictionary? and c) any good links to tutorials/examples that might go into what I'm trying to do rather than just a custom control creation tutorial.
You definitely want a ResourceDictionary with styles that you will be using in other apps. You can then reference it on an application, window, or even control level by including it in the application, window or control resources.
Where you put that resource dictionary isn't that important, though a custom control project is a common place to do so. It can be anywhere, in any project, and you can reference it with a URI.
Microsoft has a pretty good writeup on resources: Using Resources. Here's a decent tutorial on using dictionaries: Resource Dictionaries
You are in the right direction with ResourceDictionary. Create one for your application in a separate library move all your Styles there and refer them using Pack URI syntax. Here is a related question: ResourceDictionary in a separate assembly
In WPF applications all the views are inherited from System.Windows.Window and have an associated xaml and codebehind file. That seems logical.
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)? I know that this file is usually used to define application resources, etc, and xaml provides an efficient way of defining them. But that can also be done programatically. Then what benefit did the designers of wpf achieve by having both the xaml and code behind files for "App"? Wouldn't one of them have been enough?
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)?
Remember that XAML is not a UI language, but a general declarative language. While it's true that it's mostly used to represent UI for WPF or SilverLigth, it's also used to declare graph of objects in other non-UI technology.
The first example that comes into my mind is the Workflow (the XOML is a derivate of the XAML), SharePoint also use XAML in some hidden parts, and I've seen in a customer project with use XAML as a meta-language for generating web-apps (and yes, it actually outputs HTML).
Then, to answer to your question, the application have both files (and it is not actually a requirement) because you can :
declare some objects (in the xaml)
override the behavior of the application (by overriding appropriate methods)
Designers can specify resources for entire application without entering any code and use it in any Window. Its something like a root for all windows. For example, if you use one style for every TextBox (or any other control) in every window, you can specify it in App.xaml and bind anywhere without duplicating.
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 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.