I hate every time I am working on something and I have to implement INotifyPropertyChanged. My DRY-dey sense tingles*.* Not only am I forced to not use auto-properties (1st DRY violation), I’m forced to fire the event in each setter (2nd DRY violation), and specify the name of the property that is getting set, inside of that property’s setter (3rd DRY violation). That much WET (read: not-DRY), for something so simple leaves me a little grumpy.
I’ve been on this quest before, to simplify this a bit, but it was still a little hackety, and limiting.
This time, I set out to do it right.
I’ll spare you most of the technical details, but it’s backed by Castle’s DynamicProxy project, and there’s some integration with StructureMap to make it super easy, though you don’t really have to use StructureMap if you don’t want to. [note: I’ll probably add more container support as I find time. If you have a specific need, let me know, or submit a patch.]
Here are the codez to show it in action:
Basics
Using it for a class with an interface
Note: The attribute goes on the interface, not the class.
[AutoNotify]public interface IFoo{ string Value { get; set; }}public class Foo : IFoo{ public string Value { get; set; }}Using it for a class
[AutoNotify(Fire = FireOptions.OnlyOnChange)]public class Foo{ // note: for autonotify to work, the property must be virtual public virtual string Value { get; set; }}The previous example shows how to get the event to fire only when the value is different also. It defaults to always firing, whether the value changes or not. It’s also important to note that your properties need to be virtual so the calls to the setter can be intercepted.
Dependent Properties
Sometimes (usually) you’ve got calculated properties that need to fire the notified event too, these usually turn into WET mess as well. We’ve got the problem solved, and you’ve got a few different options, hopefully one of them suits you.
Dependency Map – DependsOn
You specify the type that defines the DependencyMap on the attribute, and then set up your dependencies in that type’s constructor. This style is somewhat influenced by the FluentNHibernate API.
[AutoNotify(DependencyMap = typeof(ProjectDependency))]public class Project{ public virtual string Name { get; set; } public virtual string[] Files { get; set; } public virtual int FileCount { get { return Files.Length; } }}class ProjectDependency : DependencyMap<Project>{ public ProjectDependency() { Property(x => x.FileCount).DependsOn(x => x.Files); }}Dependency Map – Updates
If you’d rather express your dependency the other way around, that’s fine too. The two are equivalent.
[AutoNotify(DependencyMap = typeof(ProjectDependency))]public class Project{ public virtual string Name { get; set; } public virtual string Files { get; set; } public virtual int FileCount { get { return Files.Length; } }}public class ProjectDependency : DependencyMap<Project>{ public ProjectDependency() { Property(x => x.Files).Updates(x => x.FileCount); }}Dependency Map – UpdatesWith
If you want to stick with an auto-property, and leave the calculated property logic somewhere else, you can hook it in via your dependency map too. This example, again, is equivalent to the previous two.
[AutoNotify(DependencyMap = typeof(ProjectDependency))]public class Project{ public virtual string Name { get; set; } public virtual string[] Files { get; set; } public virtual int FileCount { get; set; }}class ProjectDependency : DependencyMap<Project>{ public ProjectDependency() { Property(x => x.Files) .Updates(x => x.FileCount) .With(x => x.Files.Length); }}DependsOn Attribute
If you don’t like any of those options and are looking for something a little more simple, maybe you’ll like this one. Just specify which things your property depends on in an attribute. You lose your 100% static typing help, but it’s more concise.
[AutoNotify]public class Project{ public virtual string Name { get; set; } public virtual string[] Files { get; set; } [DependsOn("Files")] public virtual FileCount { get { return Files.Length; } }}Containers and otherwise
Hooking it into StructureMap
There are a couple conventions you can use to hook into StructureMap. There is the attribute convention (which is what you’re seeing above), and there is a generic predicate convention that you can use any predicate logic. Below you can see the attribute one getting hooked in.
var container = new Container(config => config.Scan(scanConfig =>{ scanConfig.With(new AutoNotifyAttrConvention()); scanConfig.TheCallingAssembly(); scanConfig.WithDefaultConventions();}));var project = container.GetInstance<Project>();Using it without StructureMap
If you’re using another container, or no container at all, but want to use some other factory or something, you can do that too. This example is for something with an interface. It’s very similar to do the same for a concrete class… you just don’t instantiate the object first. You also have an opportunity to hook into the dependent property structure here as well with the DependencyMap parameter.
var foo = new Foo();var notifiableFoo = Notifiable.MakeForInterface( typeof(IFoo)), foo, FireOptions.Always, new ProxyGenerator(), DependencyMap.Empty);Assert.That(notfiableFoo is INotifyPropertyChanged);Whew, done
So… that’s a lot of ‘how to’, but hopefully it’ll be somewhat complete introduction to get you working with it. I really don’t see much of any reason to ever implement INotifyPropertyChanged ever again (unless you are in an environment where you can’t use DynamicProxy). It can automatically be done for you from now on.
The code is up on github, and there is a gem up on rubygems if you’re using nu or noodle+bundler. Fork it, send me a patch, use it, send feedback, etc. I hope you love it!
Build awesome things for fun.
Check out our current openings for your chance to make awesome things with creative, curious people.
You Might Also Like
