I'm trying to find some differences between these approaches. Is there any situation where behaviors are used and the same functionality could not be done with attached properties?
No. Behaviors are basically just a much nicer abstraction on top of attached properties.
By using Behavior<T>, you gain access to the AssociatedObject directly, as well as the ability to attach and detach the behavior, easily, at runtime.
You could do this with attached properties, but it would require adding a lot of extra plumbing.
I tend to use Behaviors to add functionality which makes visible changes. Whereas I use attached properties to add additional information to an object which is subsequently used by other objects.
E.g. Grid.Row makes a good attached property, as it's used by the Grid and not the target. On the other hand, AutoCorrect would make a good behaviour, as this will make visible changes on the object.
Behaviors are based on attached properties. That means if you can't find specific behavior - you write your own, either based on behaviors framework provided by Blend or by creating your own AP...
I always thought that behaviors are great evidence of attached properties power. Just incredible what you can get with them.
This is not the answer. But the best explanation I can find on this topic
https://web.archive.org/web/20180208143035/http://briannoyesblog.azurewebsites.net/2012/12/20/attached-behaviors-vs-attached-properties-vs-blend-behaviors/
Brian Noyes in his articles clearly describes the differences between each of the concepts.
Related
I am new to WPF MVVM .. Anybody clear the usage of the Behaviors in MVVM application in WPF?. Why we should go for Behavior even we have Method action in WPF MVVM ?
A Behavior is the thing you attach to an element and specifies when the application should respond.
The Action is attached to the behavior and defines what the application should do when the behavior is triggered.
From this article:
At a glance, a behavior looks similar to an action: a self-contained
unit of functionality. The main difference is that actions expect to
be invoked, and when invoked, they will perform some operation. A
behavior does not have the concept of invocation; instead, it acts
more as an add-on to an object: optional functionality that can be
attached to an object if desired. It may do certain things in response
to stimulus from the environment, but there is no guarantee that the
user can control what this stimulus is: it is up to the behavior
author to determine what can and cannot be customized.
And from this article:
Behaviors let you encapsulate multiple related or dependent activities
plus state in a single reusable unit.
I highly recommend reading Introduction to Attached Behaviors in WPF that demonstrates:
What is attached behavior
What are it's alternatives
It's advantages compared to alternative solutions to similar problems
The idea is that you set an attached property on an element so that you can gain access to the element from the class that exposes the attached property. Once that class has access to the element, it can hook events on it and, in response to those events firing, make the element do things that it normally would not do. It is a very convenient alternative to creating and using subclasses, and is very XAML-friendly.
Conclusion from the above article:
Hooking an event on an object and doing something when it fires is
certainly not a breakthrough innovation, by any stretch of the
imagination. In that sense, attached behaviors are just another way to
do the same old thing. However, the importance of this technique is
that it has a name, which is probably the most important aspect of any
design pattern. In addition, you can create attached behaviors and
apply them to any element without having to modify any other part of
the system. It is a clean solution to the problem raised by Pascal
Binggeli, and many, many other problems. It's a very useful tool to
have in your toolbox.
In MVVM you may need to call methods from the View if your ViewModel exposes methods, not commands. Behaviors allow for this.
You state "we have Method action in WPF MVVM", but as far as I know "method action" is not part of WPF. If you are using a helper MVVM library, it may provide "method action" that could encapsulate methods in commands. In such a case, behaviors are not required for the MVVM pattern using methods.
Note, though, that behaviors have other uses outside of MVVM.
In Silverlight (and probably WPF), when I define a System.Windows.Interactivity.Behavior<T> for e.g. an ItemsControl, like
public class SomeAwesomaticBehavior : Behavior<ItemsControl>
{
}
it will appear in Visual Studio's XAML editor (and probably in the Designer too) even for ordinary, non-Items-Controls and throw nasty runtime exceptions. This is contrary to Attached Properties which will appear only for intended types.
Is there a way to restrict that visibility? Some magic attribute maybe (although that would be a redundant declaration)?
If there is no way today, I hope there will be so in the future? Because it surely does confuse co-workers and designer folks when a lot of Behaviors pop up that don't have anything to do with the current object.
Update: I have filed uservoice items.
Silverlight: http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/1224253-restrict-behavior-visibility?ref=title
WPF: http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions/suggestions/1224259-restrict-behavior-visibility?ref=title
#HeRz you are correct, there is no way to filter behaviors by their targeted type. Blend (and probably vs designer) use reflection to find all of the types you create which inherit from base type Behavior and displays them in the assets list.
Blend will prevent you from dragging a behavior or trigger onto an item which it is not intended. So that should help prevent their misuse.
I usually try to write behaviors as reusable pieces of code, not scoped to a specific case. They are simply tools with specific purposes.
I've read in a blog the following sentence:
The first rule of WPF:
Avoid control inheritance.
I've seen similar things in other places as well.
However, I fail to understand the logic.
Moreover, I see suggestions here in StackOverflow that involves inheriting WPF controls (see the replies to my previous question for example).
I would like to understand why (and if) control inheritance should be avoided.
WPF controls are "lookless". In other words, their look is separated from their behavior. More often than not, you actually want to customize the look - not the behavior. Unlike the world of Winforms, this does not require you to inherit a new control and override rendering logic. Instead, you set some properties on the control, resorting to overriding the template itself if you can't get the look you want from other properties.
Note that "avoid" means just that. Avoid inheritance if you can. In cases where you need to modify behavior, inheritance may well be the best option.
The blog from the link also states in the end that:
"With Styles, Templates, Decorators and attached properties and behaviors you can accomplish most of the things that you used to have to roll a new control for."
That is true. However, were it always true, the wpftoolkit team wouldn't have made their DataGrid as a subclass of MultiSelector.
Judge each case separately, I would say. Also check this answer.
This question is fairly straightforward -- I am trying to debug a memory leak in a silverlight application using s.o.s. I was able to get some good info using !gcroot to determine what objects have open references to the one that should be getting cleared; but in these cases they tend to be core UI elements (like grid and storyboard), and I can't really differentiate them without the ability to see the values of their dependency properties (like name). Trying to look through the dependency properties with !dumpobj is a total wild goose chase for me, they are all static classes (the properties that is) that reference each other and I just end up going in circles. At no point was I ever able to find a single actual value for a dependency property anywhere.
I googled about this quite a bit, but was only able to find other people asking the question, or speculation not leading to an answer. http://blogs.msdn.com/tess/archive/2008/09/16/q-a-reader-emails-about-net-memory-leaks-and-random-questions.aspx is one such page without answer.
Looking at the source of DependencyObject.GetValue in Reflector makes me think that this is non-trivial to do in Windbg. As an alternative (and a hacky one, I admit), in your own classes you could bind a standard CLR property to the Name DP, so that you do have a value that you can read in the debugger.
Or do you populate your form controls manually by a method?
Is either considered a best practice?
Generally, if data binding business or DAL objects is possible, I would use it. The old axiom holds true: The most error-free and reliable line of code is often the one you didn't have to write. (Bear in mind, however, that you need to know exactly how that data binding occurs, what its overhead is, and you have to be able to trust the framework and your source objects to be error-free!)
You would, as others have mentioned, manually populate if you needed specific functionality not brought to bear directly by binding, or if there is an issue with data binding business/DAL objects (as occasionally happens with certain 3rd-party controls).
Well, it depends. I have tended to use databinding wherever I could - it is darn convenient, but on occasion, I'll populate them manually. Particularly, I find it useful with controls like the DataGridView to use databinding. It makes filtering quite simple.
It really depends from what you are trying to achieve.
Databinding is simple and powerful, but if you need more control or some kind of side effect, you can manually populate control from a method.
Personally, I start with a databinding first, than change it later if it is necessary.