I just converted all my settings from AppSettings to ConfigurationSections. It definitely cleaned things up, but I'm having difficulties with the preferences window. I want to use bindings in my WPF window.
Should I store each of the ConfigurationSections in a dependency property and bind to the ConfigurationSection's properties?
Should I use ObjectDataProvider's that calls the ConfigurationManager.GetSection?
Is there another way I can do this?
Off-topic: I find the bindings in WPF to be really powerful, but it's sometimes a bit confusing or difficult to create the bindings. I wish there was better documentation for XAML.
You don't need to do anything special - you can databind to types with plain old properties. All the stuff about dependency properties are only for WPF controls themselves. When it comes to the model against which you bind, there are no particular constraints. You can bind to Plain Old C# Objects (POCOs), although implementing INotifyPropertyChanged is an advantage.
However, instead of binding directly to your Domain objects (it sounds like your ConfigurationSections fit that role), it is often a good idea to explicitly create a ViewModel that deals with view-specific responsibilities while encapsulating the real Domain objects.
Josh Smith's article Patterns: WPF Apps With The Model-View-ViewModel Design Pattern is an excellent introduction to proper databinding in WPF.
Related
Is localization a responsibility of the View or of the ViewModel? Initially, I thought that it clearly belongs into the VM, as it is just data that needs to be displayed by the view. What exactly needs to be displayed is not important to the view. In addition, I have made the experience that XAML is more brittle than ViewModel code. But in a discussion today, some people strongly believed that localization is the responsibility of the view.
Here's some of the advantages I see for both versions:
Advantages of putting them into the View:
ViewModel is oblivious of localization
You can see the resource key in the XAML
Less code
Advantages of putting them into the ViewModel:
View is oblivious of localization
The View does not need to know anything except for it's ViewModel
It's easier to combine and create more complex strings.
In a Wpf application that uses the MVVM pattern, should the localizable elements (string resources) go into the view, or into the viewmodel? Why? What other advantages and disadvantages are there for the two approaches?
Some background info after comments: Assume that the Localization-backend is based on resx (not LocBaml). In addition, assume there was a framework that (View-Variant) could either transparently replace resource-ids in the view with the string, or that (ViewModel-Variant) would automatically generated INotifyPropertyChanged events for localized properties on the ViewModel.
However, I am mainly interested in arguments why it's better from a conceptual or cleaner-code point of view, disregarding the backend.
Some resources belong to the View, and some resources belong to the ViewModel. I do not think there is a strict rule in that matter. Use your own judgment. Personally, I'm sharing the ViewModel's resource file with the View.
To correctly implement localization in your WPF Application as it was designed, you need to follow the set procedure, so there is not really a choice like you are suggesting. For one thing. you'll need to set the Uid property on all of your UI controls, so that clearly can't be done in a view model. Furthermore, it is common to put all localized string values into separate dlls, so again, you can't do that in a view model.
I don't have the time to describe exactly how to do it right now. Instead, for full details about localization in WPF, please see the WPF Globalization and Localization Overview page on MSDN.
I thought we should have no reference from View to ViewModel in MVVM Pattern. but just saw an MVVM Sample from code.msdn.microsoft in which ViewModel implements new Window and shows it;
By using MVVM-Light toolkit you use Messenger to Call or Open new Window and Still keep Separate the View and ViewModel form each other. Is it right to reference the View in ViewModel? Or it is wrong;
Do you suggest to call Views Directly from ViewModel for large(or medium) projects?
http://code.msdn.microsoft.com/windowsdesktop/Easy-MVVM-Examples-fb8c409f
YAGNI.
Level of effort and complexity.
MVVM is just a pattern. A pattern you don't have to follow. Any little tool I write for my own use just uses a model, a viewmodel, and a view. The viewmodel exposes all properties I need for the view by INotifyPropertyChanged. The data is moved back and forth from viewmodel to model manually using ViewModel.FromModel(model) syntax. I don't bind to my models. I only use the model when saving/loading data; I don't hang onto it. My views are generated using dataTemplates and dataTemplateSelectors. If I have a property that should change the layout I expose that on the viewmodel and use a selector. Otherwise, I have a datatemplate for every viewmodel object. And it just works.
I call this a form of MVVM, even though it doesn't any toolkit or the exact MVVM pattern that Microsoft describes.
I would personally implement a service to drive commands from the viewmodel to generate new views and hookup the viewmodel. But that's because I have MVC experience, and I think generating views is easier to do using the MVC pattern, whereas desktop views work better using the MVVM pattern.
All my views are composed with contentControls. Setting the content is setting the viewmodel.
So I use a hybrid.
If your software isn't so complex to need the complete Microsoft endorsed MVVM pattern, why create the overhead code IMO. YAGNI.
IMO, having a strong reference from the ViewModel to the View has 2 problems:
It breaks the testability of your ViewModel code. This means you won't be able to Unit Test your code so easily, and if you do you'll have to account for Dispatcher issues and the like.
It makes your ViewModels dependent on WPF assemblies and types. This means you won't be able to literally copy and paste your ViewModels into other applications or platforms such as Xamarin.Android or the like
If none of these are important to you, I don't see any reason why you wouldn't. Not doing so creates additional overhead in your code, by having to implement WindowManagers and whatnot.
I'm very new to XAML. To utilize MVC architecture and the Command Pattern while taking advantage of XAML, I have started binding static ICommands to Buttons. I'm working on a fairly large project with over a hundred buttons. My questions are: are there different approaches for binding commands to buttons to avoid static objects. With regards to C#, WPF, and XAML, are statics commonly used? I'm sure someone has already worked on a project using MVC, Command Pattern, and XAML, what was your approach?
I should have probably edited this sooner, but while working on the project, I've realized how much I didn't know about c#, WPF, and XAML when I asked this question. Apparently, in WPF, instance properties make it convenient binding methods and data members to controls.
As far as MVC / MVVM are concerned, I guess I was hesitant to expose my model to VM before I even know what it is.
I think you mean the MVVM pattern as it applies to WPF. That is Model View ViewModel
Model = used to construct the form model for the data being manipulated
View = Presentation (usually a main form and many user control forms)
ViewModel = code container for presenter (classes that contain the code)
Generally your binding take the place of ICommand methods that implement a RelayCommand from a base. There is a lot to learn before implementing the MVVM model, I would suggest reading Josh Smith's article and downloading his example to get started on learning it:
There are special rules and principles to learn and this example will go through a lot of it.
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
I would also think it would be wise to learn how WPF performs bindings a little bit. There are many special setups you can do with bindings to help with performing operations at different events and other places. I do not even know all the bindings by heart but I know the more you learn them the more time you save in the end in your XAML coding as you can reuse, event trigger, inherit and do many things with bindings to make your applications more powerful than static creation.
http://msdn.microsoft.com/en-us/library/ms752347.aspx
I have a silverlight bing map application. I am using the MVVM pattern with PRISM.
The bing map has a "BoundingRectangle" property that is not available in XAML, but it is available via code behind. Of course this does me no good since I need the data in my viewmodel which doesn't have access to the View's code behind (nor do I want to add it, since I'd really like to try to not use the view's code behind if possible).
Normally, you would do a two way bind to a viewmodel property. The Bing map will surface BoundingRectangle for layers, but not for the base map (that I can find).
I'm not looking for a hack here, just wondering what the best practices or convention for getting data out of a view to a viewmodel that isn't "bindable".
Thanks!
Databinding in Silverlight is just a framework feature that automatically synchronizes data between your view and your view model (if you are following the MVVM pattern). However, there is nothing wrong with doing this yourself!
The two main advantages of the MVVM pattern (other than the usual separation of concerns that most UI patterns provide) are:
It aids unit testing, the View Model can be exercised from your unit test code without a view present.
It helps the developer / designer workflow, reducing the files shared between the designer and developer.
In my experience, having a small amount of code-behind that 'assists' the binding framework does no hard at all!
You can use techniques such as attached behaviours to wrap this code up, but often this just results in a cosmetic improvement.
CraigF,
you can use Mediator pattern, if you use Galasoft Light toolkit then use messenger to send message from view to your viewmodel. Viewmodel register to that message and if recive one set your property in viewmodel and do some logic..
I am thinking about the design of a WPF or Silverlight application. I am planning to use MVC (or another such design pattern)
Witch ever of the design patterns I choose, I need to connect to view to the model (or presenter) – is databinding a good way of doing this?
(In the past with WinForms applications I have found that Databinding give lots of problem in the long run and does not fulfil its promise. It is the same with WPF and Siverlight?)
Yes, you should definitely definitely use data binding. While WinForms and ASP.NET were always a struggle to get anything data bound consistently and in a maintainable manner, Silverlight and WPF are built from the ground up for data binding pleasure.
Binding is two-way so you don't have to write tedious plumbing code to move data in and out of your model. Just implement INotifable and away you go.
Converters allow you to write code to handle the way things are bound if the defaults aren't working. Using converters (which are dead-simple to write) you can bind booleans to visibility settings, strings to images, integers to background colors, and so on. The sky's the limit.
Patterns such as MVVM are perfect for the rich data-binding support in WPF and Silverlight. MVVM lets you have the best of both worlds: loosely coupled code together with data binding.
Element binding lets you bind the property one element to the property of another element. Together with converters, this gives you impressive power to do things like bind the current position of a slider control to the selected index of a list control. Both ways.
Deep binding means you can bind to the property of a property of your model. Not that you always should, but you can.
Binding is almost magical in its dynamic-ness. As long as your model continues to support the same bound properties, binding will continue to work even if the static type of the model changes. Binding is also crazy flexible. You can bind to collections, interfaces, complex objects, (almost) anything you like.
DataContexts can be used to set up data-binding at a page, control, or container level. Children of the container then inherit the same data-context. This lets you bind once at the page level and then use binding paths for the rest of the page.
I recommend you take a look at the Model-View ViewModel (MVVM) pattern. Here is a very good video you should take a look at: Jason Dolinger on Model-View-ViewModel. Two-way data binding in WPF is very powerful.
be it WPF or Adobe Flex or Winforms , Databinding will always give issues when the application becomes complex. I would prefer to avoid data binding for easier debugging. But data binding runs all around WPF that we can't avoid. Doing data binding in XAML takes away control from the developer.
I think , if we keep the data binding in the code , its much easier to debug.
Imagine , MVVM without data binding , it will look messy. A design pattern that takes advantage of technology is good but a design that is totally dependent on a particular feature is a disaster.
Data binding in WPF goes far beyond what you could achieve in Winforms. It is intrinsic to the platform and prevalent throughout. I would argue you can't understand WPF without understanding its data binding system.
It's not without its pitfalls, to be sure. Broken bindings are often not as obvious as you may like, but improvements have been made to help you identify and flag these issues.