tag:blogger.com,1999:blog-652174954000901332.post8614976567185847182..comments2008-07-20T06:29:12.540+01:00Øyvind Vallandhttp://www.blogger.com/profile/17595718624373482981noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-652174954000901332.post-15551967833791897212008-07-20T06:29:12.540+01:002008-07-20T06:29:12.540+01:00Hello Jonas,<BR/><BR/>Thanks for commenting! <BR/><BR/>I concede that automatic properties have their place when it comes to dumb DTOs. In a previous life I had two libraries of DTOs (one for services, one for the DAL) that had to be kept in sync with each other. E.g. there was an Address DTO in one library (exposed as a DataContract) and an Address DTO in another library used with an Object-Relational Mapper (iBatis). Both classes would implement IAddress which defined all the properties on the interface. Without automatic properties maintaining and building these classes were a <I>real</I> pain. <BR/><BR/>As for the alternative to automatic properties (which you've appropriately wrapped in double quotes), I think it isn't an alternative unless you have a very good reason to expose a field directly - which isn't often.<BR/><BR/>A lot of developers like to use properties for more than simple member variable access. Not that it's an example of good practice, perhaps, but having the ability to add some validation on a setter can be useful and it's a shame that this isn't supported with automatic properties. I like your idea of using events for this, and I can only hope that MS gives us a dual solution where you can use events <I>or</I> create an automatic property where you can inject some code and work on the "value" parameter.Øyvind Vallandhttp://www.blogger.com/profile/17595718624373482981noreply@blogger.comtag:blogger.com,1999:blog-652174954000901332.post-41587957663205984722008-07-20T05:36:59.589+01:002008-07-20T05:36:59.589+01:00Hi Øyvind!<BR/><BR/>Again, another fine blog post :)<BR/><BR/>Here are some comments on why automatic properties matter.<BR/><BR/>1) You can't databind against public fields. Alot of times you have really dumb data transfer objects, for instance the one automaticly generated by the web service proxy tools. This tool now generates classes with automatic properties so that you can bind against them.<BR/><BR/>2) The "alternative" to a automatic property (a property with no backing set or get logic) is a public field. You might expose a public field, and lather when needed wrap it in a property. The problem with this is that changing from a field to a property changes the public interface of your class, so anything that is compiled against that class has to be rebuilt.<BR/><BR/>If you're using an auotmatic property with no set or get logic, you can change this class later on, recompile, and not have changed the public interface of your class.<BR/><BR/>3) It's just handy.. It saves time and keeps your code compact. There is no underlaying changes in the CLR, and if you dissasemble your code you will find a set_Name and a get_Name method, and a _name backing property.<BR/><BR/>Personally I allways use automatic properties unless I know I'm going to change it, if so I use one of the properties code snippes to have a property with a get and set set up for my real quickly. Would also be cool if you could add some aspect oriented programming behaviour to automatic properties. Like saying this property should trigger the INotifyPropertyChanged.PropertyChanged event... :)<BR/><BR/>Cheers,<BR/>Jonas FollesøJonas Follesøhttp://www.blogger.com/profile/03186489878623898246noreply@blogger.com