What is the best way, not using "brute force", to find out all attached and dependency properties of an object or type?
Related
I have a winform which contains a usercontrol. That usercontrol has a dependency which I need to resolve using unity. The problem with using constructor injection is that the user control is instantiated in the InitializeComponent of the designer of the winform. Hence I cannot place container.Resolve over there.
What is the alternative?
I believe you will want to use Property Injection and BuildUp:
Using BuildUp to Wire Up Objects Not Created by the Container
Constructor injection is generally the preferred method, but as you noted it's not possible when dealing with WinForm controls.
I have spent countless hours reading and researching this topic – and I just can’t seem to get a foothold on it. Here is my scenario:
I write software for a company that provides asset-tracking (with some added features). We currently have an ASP.NET based website using the googlemaps api. So this is what I am comfortable with.
I have now been tasked with writing a WPF application with much of the same functionality but instead using the wpf bing maps api.
I have messed around with the map and figured out (non-mvvm way) how to draw custom pushpins, polygons, etc… Now I need to use the databinding features. This is where I just can’t seem to put the two together. Basically what I am trying to do is bind a collection of a custom class that creates a custom pushpin, to a MapControlItem.
The documentation is just a bit too fragmented and abstract for me to grab on to something – or maybe I am just too much of a web developer and really struggling to grasp a concept that is new to me.
Any ideas? Examples?
You're right, the Bing Maps WPF Control API documentation is a joke.
Anyway, you would have to use a MapItemsControl and bind its ItemsSource property to your item collection. The ItemsContainerStyle and/or ItemTemplate properties would define the UI objects that are shown on the map.
You may start reading about Data Binding to Collections.
I only played with the Windows 8 version of the Bing maps control, not the WPF one, so I apologize if my answer is not quite apropriate.
What I know, is that in windows 8, you just can't apply bindings, for MapLayers or MapChildren.
From what you describe, I believe you just can't do a binding on these properties in WPF, simply because they are not dependency properties.
So only 1 solution left, in you window's code-behind, subscribe to your ViewModel's PropertyChanged event, and manually apply any updates you need to your control.
Anoter way to do that, is to create a UserControl, which will simply display a BingMaps control, and add to this userControl a "BingMapsContext" (or whatever) dependency property, to manually update the map control when that specific property will be binded.
I am designing a WPF application using MVVM and I am experimenting with the UnityContainer to resolve my MVVM objects. My problem is that my UnityContainer needs references to all my Views and ViewModels to construct the appropriate object that I need. This is fine except when one of those ViewModels needs to open a new window. To handle this I thought of having a DialogService that would get MVVM objects from the UnityContainer and then open the new window. This ends up creating a circular dependency because my ViewModel needs to see the DialogService, the DialogService needs to see the UnityContainer, and my UnityContainer needs to see my views and viewmodels. I'm not using Prism or anything just the UnityContainer installed form Nuget. The following is a pseudo-code simplified version of my problem.
Assembly-Interfaces (I reference nobody)
IViewX
IViewY
IViewModelX
IViewModelY
Assembly-Views (I reference Interfaces)
ViewX : IViewX
ViewY : IViewY
Assembly-ViewModels (I reference Interfaces and DialogService) <- this is circular dependency
ViewModelX : IViewModelX
ViewModelY : IViewModelY
Assembly-MyUnityContainer (I reference Interfaces, Views, and ViewModels)
UnityService (provides access to the UnityContainer)
Assembly-DialogService (I reference Interfaces and MyUnityContainer)
DialogService
Obviously my design is flawed. I'm just not sure what is the right way to use the UnityContainer from anywhere since it has to have references to everywhere in order to resolve my Views and ViewModels. So those of you experienced with using UnityContainer what am I doing wrong and how would you recommend I design this? Btw I am using WPF 4.5.
Note: My problem is design related, I literally cannot add a reference to my DialogService in my ViewModel, VS won't allow it. This is not the problem where a circular dependency causes a stack overflow. Just wanted to make that clear.
Thanks!
EDIT: RESOLUTION
As per the advice I received I ended up doing a design similar to the following.
Design: How assemblies reference each other.
The MainApp sees everything, so it creates the UnityContainer, registers all of the types and hands it to the DialogService assembly as an IUnityContainer. Now the DialogService assembly can resolve any interface type without knowing about the concrete implementations. The ViewModel can use DialogService to create dialog services, which in turn open windows or other dialogues. The ViewModel just needs to know about the interface that it wants to open and give that to the DialogService, the dialog service does the work of opening the window.
I would say that ideally, Assembly-MyUnityContainer is the one that should reference everything.
So in order to break the dependency from Assembly-DialogService to Assembly-MyUnityContainer, you need to stop depending on interfaces or classes in Assembly-MyUnityContainer from Assembly-DialogService.
Why not add your own IContainer interface to your interfaces assembly, which abstracts the Unity Container? Then have the dialog service assembly only refer to the interfaces assembly...
I understand that dependencies properties serve a major purpose in WPF. However I do not get the reasons behind the restriction that in binding, the target property must be a dependency property. Why can't it be any property?
If you're interested, you might open up Reflector and take a look at some of the code related to dependency properties and the binding system in the framework. There is a lot of tricky stuff going on to allow robust, performant resolution of property paths and propagation of changes to dependency properties. Having a standard infrastructure also allows for management of more complex use cases, such as updating a dependency property from more than one source and resolving the priorities. This comes up frequently when animating a property that has its default set by a style, for example.
The other nice thing with dependency properties is that they internally encapsulate a lot of behavior (such as notification, validation and coercion), which means if you see a dependency property, you know that certain behavior will definitely be supported. This is in contrast with INotifyPropertyChanged, where the class implementer may or may not be supporting the interface as advertised. This means less work for class developers.
A simple search in google with DependencyProperty yields some results, which you might find relevant. For instance: http://blog.hackedbrain.com/articles/UnderstandingDependencyObjectAndDependencyProperty.aspx
And I guess one of the reasons would be context. Binding is built into the infrastructure of WPF, but a C# class property does not belong there. Inorder for the WPF infrastructure to find bindable properties you must declare them in code. Also if you declare your properties, you give important metadata for the WPF infrastrtucture.
Although I do agree that it would be easier if it were possible to bind to regular properties, but this is certanly a case of don't bother your precious brain with minor details...
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.