Ayende @ Rahienhttp://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660John Rusk commented on An easier way to manage INotifyPropertyChangedHere's another alternative [http://www.codeplex.com/ActiveSharp](http://www.codeplex.com/ActiveSharp) Properties have their real types (no .Value) . http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment32http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment32Tue, 11 Aug 2009 09:15:25 GMTMatt Fenner commented on An easier way to manage INotifyPropertyChanged"Jonathon, I really hate all the craft that you need to get it working" I would argue that there is more craft here. Also Dependency Properties are implemented in a way which actually makes them perform better in bindings because the framework doesn't have to use reflection. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment31http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment31Mon, 10 Aug 2009 01:51:16 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedMicahel, In about 12 hours there is going to be a post about Conditions and Facts, take a look at this http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment30http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment30Sun, 09 Aug 2009 21:07:10 GMTMichael L Perry commented on An easier way to manage INotifyPropertyChangedAyende, Fair enough. Could you demonstrate then how you would update your view model from the data model? For example, set AllowEditing when certain conditions are true? The reason I define a view model to have no storage is because it allows you to write what AllowEditing means in just one place: the getter. If it has storage, you have to set that storage from someplace else, usually from a property changed event handler. That's seems like extra work to me. I'm curious to see how you solve that. Thanks. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment29http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment29Sun, 09 Aug 2009 20:28:41 GMTchris Donnan commented on An easier way to manage INotifyPropertyChangedRadenko; Validation is a separate concern. We have CommandModels ala this [blogs.msdn.com/.../756095.aspx](http://blogs.msdn.com/dancre/archive/2006/09/15/756095.aspx) Each CommandModel has a Validator on it. Each validator is essentially a Func <t,validationresult> where the result has potential messages and a bool on it. This lets us compose validations together using a CompositeValidator (list of those Funcs basically). Each command is bound to the UI, we bind all our validators to enable the commands and to show messages (eg; we put tooltips over disabled buttons with the errors etc). That is about it. Chris http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment28http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment28Sun, 09 Aug 2009 15:08:23 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedMichael, Then we don't share the same definition at all. The model in the post is my view model. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment27http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment27Sun, 09 Aug 2009 10:51:48 GMTRadenko Zec commented on An easier way to manage INotifyPropertyChangedAyende nice code. Chris Donnan how to do some additional validation on properties then? Thanks http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment26http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment26Sun, 09 Aug 2009 09:17:11 GMTChris Donnan commented on An easier way to manage INotifyPropertyChangedI have done this for our WPF based projects for ~1 year. I have been calling this PropertyModel. We have also included other presentation specific per-property metadata in our property model types. IPropertyModel <t : INotifyPropertyChanged { T Value bool IsEditable string CustomEditorName void SignalChanged() ...etc } This has made many of our binding scenarios much cleaner. We have also made a series of policies that toggle propertymodel settings. This has given us generally more reuse of common screens. For example our New and Edit screens are the same. The edit screens let us flip certain IsEditable values to false and so on. 'Serial related properties' often manifest in classes like: class X { Foo a; bool isADirty; bool wasAUserEntered; } This initial smell + the ugly repetitive INotifyPropertyChanged business helped us to normalise our property related data into 1 PropertyModel. PropertyModel + ViewModel + CommandModels (ala Dan Crevier) is our essential WPF model. -Chris- >http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment25http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment25Sun, 09 Aug 2009 07:37:32 GMTAndrey Shchekin commented on An easier way to manage INotifyPropertyChangedYou can also pick Obtics ( [http://obtics.codeplex.com/](http://obtics.codeplex.com/)), and you'll get real-time updates for calculated values (including Linq). I really love real-time Linq with WPF -- it completely removes the need to think what changed when and what was affected. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment24http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment24Sun, 09 Aug 2009 07:07:49 GMTMichael L Perry commented on An easier way to manage INotifyPropertyChangedAyende, The distinction I draw between Model (or more precisely Data Model) and View Model is this. A Data Model is persistent. A View Model is dependent. What you've proposed here works for the Data Model because it has storage. But it does not work for a View Model. A View Model has no storage; all of its properties are calculations that bring together properties of the Data Model. For example: class ContactListViewModel { public string Title { get { Person selectedPerson = _navigation.SelectedPerson; return "Contacts - " + selectedPerson.LastName + ", " + selectedPerson.FirstName; } } } Navigation and Person both persist data (Navigation only temporarily, but Person persistently). ContactListViewModel stores nothing. It's properties are dependent on others. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment23http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment23Sun, 09 Aug 2009 04:13:18 GMTDamien Guard commented on An easier way to manage INotifyPropertyChangedImplicit operators can be called with null so you should put a check there to return null or you may end up with null reference errors acessing .value. [)amien http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment22http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment22Sat, 08 Aug 2009 20:46:10 GMTFrank Quednau commented on An easier way to manage INotifyPropertyChangedYou wouldn't believe how annoying I find the lost instance issue with the reverse implicit operator :) http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment21http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment21Sat, 08 Aug 2009 20:24:31 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedMichael, Make a distinction between a model and view model http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment20http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment20Sat, 08 Aug 2009 19:51:59 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedMark, Both ways meaning implementing two way implicit conversion operators. The problem is that it would generate different instances. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment19http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment19Sat, 08 Aug 2009 19:50:00 GMTJohn Chapman commented on An easier way to manage INotifyPropertyChangedFirst, I don't think I would ever use something like this. I don't mind the extra work, and using the wrapper classes seems like just as much extra work anyway. You've also introduced .Value all over your usages (no implicit conversion on assignment). That being said, why did you choose to use a class instead of a struct? I would actually expect to keep value semantics versus reference semantics. It seems very odd to wrap up an integer as a class to me. You also have potential performance improvements (thought doubtful to matter in 99% of the applications out there) considering that many view model type objects contain a significant number of value types. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment18http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment18Sat, 08 Aug 2009 18:23:34 GMTMichael Sync commented on An easier way to manage INotifyPropertyChangedI'm regular reader of your blog but for this one, I don't agree with you. I prefer to have the actual type (e.g. int PersonID ) instead of this (e.g. Observe <int PersonID ). I feel like it makes my Model look ugly. Sorry. >http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment17http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment17Sat, 08 Aug 2009 17:41:23 GMTJustin Chase commented on An easier way to manage INotifyPropertyChangedYou might want to pick a name other than Observable <t since there actually will be an Observable <t in .net 4 which does something very different. [themechanicalbride.blogspot.com/.../...events.html](http://themechanicalbride.blogspot.com/2009/07/introducing-rx-linq-to-events.html)> If you haven't seen this yet you should definitely check it out, very brain bending and revelatory. My favorite quote: "To put things in perspective it’s been 13 years since Design Patterns was published and we’ve only now realized that the Observable pattern and the Iterator pattern are actually the same pattern." http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment16http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment16Sat, 08 Aug 2009 16:55:03 GMTMark Nijhof commented on An easier way to manage INotifyPropertyChangedSorry, you said "you can treat the object as if it wasn’t a wrapper for reading purposes. I could make it both ways" I understand how this works for reading, but I didn't know you could do the same for writing values to the .Value property. F.ex: AllowEditing = true would work than? -Mark http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment15http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment15Sat, 08 Aug 2009 15:27:03 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedI don't understand the question http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment14http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment14Sat, 08 Aug 2009 15:23:56 GMTMark Nijhof commented on An easier way to manage INotifyPropertyChangedHow can you make the wrapper both ways? http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment13http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment13Sat, 08 Aug 2009 15:23:02 GMTMichael L Perry commented on An easier way to manage INotifyPropertyChangedHere's an even easier way. Don't! [http://updatecontrols.net](http://updatecontrols.net) Update Controls automatically discovers dependencies among your properties and updates your WPF, Silverlight, and even Winforms controls. The problem with INotifyPropertyChanged is not firing events. It's being the middle man. The View Model layer is hard to write because you have to respond to changes in the Data Model, update yourself, and forward events to the View. But when you use Update Controls, there is no data binding code in the View Model at all. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment12http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment12Sat, 08 Aug 2009 14:17:57 GMTFallenGameR commented on An easier way to manage INotifyPropertyChangedAnd how would you implement validation if it is needed? Extend Observable with 'void Validation( string propertyName )'? http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment11http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment11Sat, 08 Aug 2009 13:49:03 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedFallen, I don't as of yet. I'll deal with that if/when I run into that scenario http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment10http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment10Sat, 08 Aug 2009 13:34:18 GMTFallenGameR commented on An easier way to manage INotifyPropertyChangedWhat about validation? In WPF it's convinient to run validation in properties. When validation fails exception is thrown and 'ValidatesOnExceptions=True' in binding allows to visually accent wrong field and show tooltip with explanation. How do you propose to handle validation? http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment9http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment9Sat, 08 Aug 2009 13:19:48 GMTStephen commented on An easier way to manage INotifyPropertyChangedYea postsharp is a potential, more and more recently I've been thinking about what I think is one of the lacking areas in '.NET', and thats where we don't have really any control at compilation time (sure we can do pre-processors etc but thats not exactly simple).. There are tons of places we end up pushing complex work to runtime that could well be evaluated once at compile time, I really think .NET needs a built in system that runs after compilation to IL, and can run transforms.. just as postsharp is allowing. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment8http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment8Sat, 08 Aug 2009 13:14:36 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedJonathon, I really hate all the craft that you need to get it working http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment7http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment7Sat, 08 Aug 2009 13:12:29 GMTAyende Rahien commented on An easier way to manage INotifyPropertyChangedLiviu, You wouldn't be able to measure that in any meaningful way http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment6http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment6Sat, 08 Aug 2009 13:11:41 GMTSean Kearon commented on An easier way to manage INotifyPropertyChangedAlso worth checking out PostSharp ( [www.postsharp.org](http://www.postsharp.org)) for a solution to this. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment5http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment5Sat, 08 Aug 2009 13:04:11 GMTFred Hirschfeld commented on An easier way to manage INotifyPropertyChangedThe default VS2008 WCF service proxy generator already takes care of the INotifyPropertyChanged on your model objects at least for Silverlight. I am thinking to augment this so it will also add the IEditableObject like I think the RIA Services does. http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment4http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment4Sat, 08 Aug 2009 11:12:47 GMTPhilipp Sumi commented on An easier way to manage INotifyPropertyChangedThinking outside the box pays off I'd say - smart solution :) http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment3http://ayende.com/4107/an-easier-way-to-manage-inotifypropertychanged#comment3Sat, 08 Aug 2009 10:46:41 GMT