Considering a class with a large number of properties, I want to implement a Dirty flag (in order to know if I should update the value in the database).
Is there any way to raise PropertyChanged on All the properties without having to manually go through and pluck it in the setter?
Edit to clear up some things: I did go through the thread that was linked here, and found some things, but unfortunately they do not suit my need. I don't really need to send an event, I just need to flip a flag. Also, that thread is quite old, and I hoped that maybe with C# 7 something came out which would help with it, that I missed in the changelog.
Why don't I just go and do it manually? Well, I might have to. But I'd have to declare the "hidden" variables, manage the code myself, I hoped MS would've done something to help, maybe something like was suggested in the other topic
public Type Name {get; set; notify { () => IsDirty = true; }}
that would help a lot (ignoring the fact it would ask me to declare the get and set anyways because they're abstract.
Add a method that looks like this:
public void Test()
{
if(PropertyChanged != null)
PropertyChanged(new PropertyChangedEventArgs(null));
}
Passing a null or empty string as the property name tells consumers that all properties have been changed.
https://msdn.microsoft.com/en-us/library/system.componentmodel.propertychangedeventargs.propertyname(v=vs.110).aspx
You can but its also a lot of work. Make an Attribute and use it on those properties. in the base class of your ViewModel,
which will implement INotifyPropertyChanged,
You register in its Constructor to the PropertyChanged event and check via reflection if the property that changed has your attribute on it,
and then set IsDirty accordingly.
Related
First off, I have read through a list of postings on this topic and I don't feel I have grasped properties because of what I had come to understand about encapsulation and field modifiers (private, public..ect).
One of the main aspects of C# that I have come to learn is the importance of data protection within your code by the use of encapsulation. I 'thought' I understood that to be because of the ability of the use of the modifiers (private, public, internal, protected). However, after learning about properties I am sort of torn in understanding not only properties uses, but the overall importance/ability of data protection (what I understood as encapsulation) within C#.
To be more specific, everything I have read when I got to properties in C# is that you should try to use them in place of fields when you can because of:
1) they allow you to change the data type when you can't when directly accessing the field directly.
2) they add a level of protection to data access
However, from what I 'thought' I had come to know about the use of field modifiers did #2, it seemed to me that properties just generated additional code unless you had some reason to change the type (#1) - because you are (more or less) creating hidden methods to access fields as opposed to directly.
Then there is the whole modifiers being able to be added to Properties which further complicates my understanding for the need of properties to access data.
I have read a number of chapters from different writers on "properties" and none have really explained a good understanding of properties vs. fields vs. encapsulation (and good programming methods).
Can someone explain:
1) why I would want to use properties instead of fields (especially when it appears I am just adding additional code
2) any tips on recognizing the use of properties and not seeing them as simply methods (with the exception of the get;set being apparent) when tracing other peoples code?
3) Any general rules of thumb when it comes to good programming methods in relation to when to use what?
Thanks and sorry for the long post - I didn't want to just ask a question that has been asked 100x without explaining why I am asking it again.
1) why I would want to use properties
instead of fields (especially when it
appears I am just adding additional
code
You should always use properties where possible. They abstract direct access to the field (which is created for you if you don't create one). Even if the property does nothing other than setting a value, it can protect you later on. Changing a field to a property later is a breaking change, so if you have a public field and want to change it to a public property, you have to recompile all code which originally accessed that field.
2) any tips on recognizing the use of
properties and not seeing them as
simply methods (with the exception of
the get;set being apparent) when
tracing other peoples code?
I'm not totally certain what you are asking, but when tracing over someone else's code, you should always assume that the property is doing something other than just getting and setting a value. Although it's accepted practice to not put large amounts of code in getters and setter, you can't just assume that since it's a property it will behave quickly.
3) Any general rules of thumb when it
comes to good programming methods in
relation to when to use what?
I always use properties to get and set methods where possible. That way I can add code later if I need to check that the value is within certain bounds, not null etc. Without using properties, I have to go back and put those checks in every place I directly accessed the field.
One of the nice things about Properties is that the getter and the setter can have different levels of access. Consider this:
public class MyClass {
public string MyString { get; private set; }
//...other code
}
This property can only be changed from within, say in a constructor. Have a read up on Dependency Injection. Constructor injection and Property injection both deal with setting properties from some form of external configuration. There are many frameworks out there. If you delve into some of these you will get a good feel for properties and their use. Dependency injection will also help you with your 3rd question about good practice.
When looking at other people's code, you can tell whether something is a method or a property because their icons are different. Also, in Intellisence, the first part of a property's summary is the word Property.
You should not worry about the extra code needed for accessing fields via properties, it will be "optimized" away by the JIT compiler (by inlining the code). Except when it is too large to be inlined, but then you needed the extra code anyway.
And the extra code for defining simple properties is also minimal:
public int MyProp { get; set; } // use auto generated field.
When you need to customize you can alway define your own field later.
So you are left with the extra layer of encapsulation / data protection, and that is a good thing.
My rule: expose fields always through properties
While I absolutely dislike directly exposing fields to the public, there's another thing: Fields can't be exposed through Interfaces; Properties can.
There are several reasons why you might want to use Properties over Fields, here are just a couple:
a. By having the following
public string MyProperty { get; private set; }
you are making the property "read only". No one using your code can modify it's value. There are cases where this isn't strictly true (if your property is a list), but these are known and have solutions.
b. If you decide you need to increase the safety of your code use properties:
public string MyProperty
{
get { return _myField; }
set
{
if (!string.IsNullOrEmpty(value))
{
_myField = value;
}
}
}
You can tell they're properties because they don't have (). The compiler will tell you if you try to add brackets.
It's considered good practise to always use properties.
There are many scenarios where using a simple field would not cause damage, but
a Property can be changed more easily later, i.e. if you want to add an event whenever the value changes or want to perform some value/range checking.
Also, If you have several projects that depend on each other you have to recompile all that depend on the one where a field was changed to a property.
Using fields is usually practiced in private classes that is not intended to share data with other classes, When we want our data to be accessible by other classes we use properties which has the ability to share data with other classes through get and set which are access methods called Auto Properties that have access to data in private classes, also you can use both with access modifiers Full Property in the same class allowing the class to use data privately as data field and in the same time link the private field to a property that makes the data accessible to other classes as well, see this simple example:
private string _name;
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
The private string _name is used by the class only, while the Name property is accessible by other classes in the same namespace.
why I would want to use properties instead of fields (especially when it appears I am just adding additional code
You want to use properties over fields becuase, when you use properties you can use events with them, so in a case when you want to do some action when a property changes, you can bind some handlers to PropertyChanging or PropertyChanged events. In case of fields this is not possible. Fields can either be public or private or protected, in case of props you can make them read-only publicly but writable privately.
any tips on recognizing the use of properties and not seeing them as simply methods (with the exception of the get;set being apparent) when tracing other peoples code?
A method should be used when the return value is expected to be dynamic every-time you call, a property should be used when the return value is not that greatly dynamic.
Any general rules of thumb when it comes to good programming methods in relation to when to use what?
Yes, I strongly recommend to read Framework Design guidelines for best practices of good programming.
Properties are the preferred way to cover fields to enforce encapsulation. However, they are functional in that you can expose a property that is of a different type and marshal the casting; you can change access modifiers; they are used in WinForms data binding; they allow you to embed lightweight per-property logic such as change notifications; etc.
When looking at other peoples code, properties have different intellisense icons to methods.
If you think properties are just extra code, I would argue sticking with them anyway but make your life easier by auto-generating the property from the field (right-click -> Refactor -> Encapsulate Field...)
Properties allow you to do things other than set or get a value when you use them. Most notably, they allow you to do validation logic.
A Best Practice is to make anything exposed to the public a Property. That way, if you change the set/get logic at a later time, you only have to recompile your class, not every class linked against it.
One caveat is that things like "Threading.Interlocked.Increment" can work with fields, but cannot work with properties. If two threads simultaneously call Threading.Interlocked.Increment on SomeObject.LongIntegerField, the value will get increased by two even if there is no other locking. By contrast, if two threads simultaneously call Threading.Interlocked.Increment on SomeObject.LongIntegerProperty, the value of that property might get incremented by two, or by one, or by -4,294,967,295, or who knows what other values (the property could be written to use locking prevent values other than one or two in that scenario, but it could not be written to ensure the correct increment by two).
I was going to say Properties (setters) are a great place to raise events like NotifyPropertyChanged, but someone else beat me to it.
Another good reason to consider Properties: let's say you use a factory to construct some object that has a default constructor, and you prepare the object via its Properties.
new foo(){Prop1 = "bar", Prop2 = 33, ...};
But if outside users new up your object, maybe there are some properties that you want them to see as read-only and not be able to set (only the factory should be able to set them)? You can make the setters internal - this only works, of course, if the object's class is in the same assembly as the factory.
There are other ways to achieve this goal but using Properties and varying accessor visibility is a good one to consider if you're doing interface-based development, or if you expose libraries to others, etc.
I am trying to implement a very simple and more importantly optional object tracking system similar to how entity framework tracks object changes (How change tracking works in Entity Framework).
I have a base class that all other objects inherit from. This class has 1 boolean field called modified. The explicit solution to this is to update every setter on all properties of other classes to set modified = true when the setter is triggered. This solution has been presented in detail here Create an event to watch for a change of variable.
I want a more implicit solution to this. I have a lot of objects and a LOT of properties. Updating the setter is incredibly messy. I don't want to directly mimmic how entity framework does things because it is too expensive for my current requirements. I want a list of objects that i can loop to check of modified == true. This allows me to optionally track object and quickly check if they have changed without having to trigger an update for each individual object. Is there a way that i can set some sort of listener on all of the property getter and setters implicitly?
I know this code doesnt exist, but does .NET have a way to monitor the object to see if it has changed.
[OnChange=ObjectChanged()] //maybe this way
public class MyClass
{
bool modified {get; set;}
public MyClass() : OnChange(ObjectChanged) //or this way
{
}
private void ObjectChanged()
{
modified = true;
}
}
As i mentioned, i dont want to update every setter or copy what entity framework does.
There's nothing built-in in the .NET framework for this, but there are third-party tools to do exactly that.
One such option would be Fody/PropertyChanged, which injects OnPropertyChanged calls into all automatic property setters of your classes. You can subscribe to the PropertyChanged event and update your Boolean flag. As an additional bonus, (a) you get the name of the property that changed and (b) other classes (e.g. your UI framework) can subscribe to the event as well.
I have a class property that looks as follows:
public List<Recipe> RecipeList
{
get { return this._recipeList; }
set
{
this._recipeList = value;
OnPropertyChanged("RecipeList");
}
}
In another method I have the following which references the property above.
private void RecipeSearch()
{
this.RecipeList = RecipeManagerService.SearchByUnit(SearchCriteria)
.Where(recipe => recipe.IsApproved == true && !recipe.IsHidden).ToList();
}
Code Analysis is issuing a CA 2227 warning: Change RecipeList to be read-only by removing the setter. Could anyone tell me why?
Adding a public setter on a List<T> object is dangerous. You can eliminate this warning by making your setter private:
public List<Recipe> RecipeList
{
get { return this._recipeList; }
private set
{
this._recipeList = value;
OnPropertyChanged("RecipeList");
}
}
This will still allow your class to change this method, but no external source.
I think it's suggesting that usually collection properties themselves shouldn't be mutable - it's more common for the collection to be mutable, and just available via a setter.
It's only a suggestion though :)
In this case you'd use:
RecipeList.Clear();
RecipeList.AddRange(RecipeManagerService
.SearchByUnit(SearchCriteria)
.Where(r => r.IsApproved && !r.IsHidden));
Note that this won't fire the change event though... you might want to use ObservableCollection instead.
This will also mean that anyone can change the contents of the recipe list... do you definitely want that? Another alternative is to expose a ReadOnlyCollection<T> property or something like that, and only make changes within your own class. It really depends what you're trying to do though.
Do you want another instance messing with RecipeList? Generally, I don't let anything change my collection instances except the instance that owns the collection. You could make it private.
The MSDN description is fairly clear:
A writable collection property allows
a user to replace the collection with
a completely different collection
It wouldn't be good OO if the client of your class could change the list to be a completely different list of Recipes. That is against encapsulation.
Ensuring the clients just add or remove items is what you probably want to do.
I don't think there's anything illegal about the code, but it's common practice to have no public setter for collection type properties. Your private RecipeSearch method should just set _recipeList and raise the event, or you could make _recipeList itself a protected property that handles the event.
Allowing the list property to be mutated in two ways (via it's own Add and Remove methods and the list instance as a whole) creates an ambiguous interface to those who consume that property. This confuses responsibilities and creates a larger technical debt/maintenance overhead.
Instead, it is often better practise to separate these concerns so that the property provides access to a single instance of the list. If the list instance must be changeable, a separate mechanism for doing so makes it much clearer that the action of interacting with the property and the action of changing which list instance that property points to are distinct.
I'd like to implement the ViewModel part of WPF's MVVM pattern without referencing WPF assemblies. The problematic part is command routing, which requires that ViewModels implement properties of type ICommand so that command bindings can work.
Now, I can avoid the ICommand and simply declare the properties as object. Everything still works, so that's that. But what bothers me is, I still have to declare them, and I really don't want to, because they feel like boiler plate code.
My ViewModels currently look like this:
public class HelloWorldViewModel : ViewModel
{
[BoundProperty]
public string Name { get; set; }
[CommandHandler("SayHello")]
public bool CanSayHello()
{
return Name != "" && Name != null;
}
[CommandHandler("SayHello")]
public void SayHello()
{
View.ShowMessage("Hello, {0}!", Name);
}
public object SayHello { get; private set; }
}
The CommandHandlerAttribute enables runtime discovery of command handlers (an Action and an optional Func<bool>), while the BoundPropertyAttribute is really an aspect that injects itself into the property setter and calls INotifyPropertyChanged. I accompish this by using a compile time IL weaver.
Ideally, I'd like to make the last line (the SayHello property) implicit, too. There would be no point in having it there in the source if it wasn't for WPF's requirement.
So, naturally, I'm thinking of using the CommandHandlerAttribute aspect to inject the necessary IL into class and essentially creating the property post-compile. This is quite hard, although a good IL weaver (such as PostSharp) can go a long way to make it easier.
Before I embark on this journey, I'd like to hear what you all think of my approach. Is it sound? Is there a better way? How would/do you do it?
To me this sounds too clever by far. There's too much "magic" happening. In particular, I dislike the magic strings and other aspects of your CommandHandlerAttribute. That said, if I were to go down this route, I'd use something akin to the EventAggregator but for commands. IOW, SayHello wouldn't exist on your ViewModel at all. What ever magic creates the command bindings to SayHell() and CanSayHello() would instead locate the command in the global CommandAggregator. As long as we're using magic strings for this, the commands in the CommandAggregator could be lazily created, thus requiring no "boiler plate" coding on your part. All that's left is to create some XAML magic (markup extension) to specify the command on the ICommandSource.
<Button Command="{my:AggregateCommand SayHello}"/>
i advice you to see how this was implemented, and it will help:
"Kind Of Magic"
Effortless INotifyPropertyChanged
[http://visualstudiogallery.msdn.microsoft.com/d5cd6aa1-57a5-4aaa-a2be-969c6db7f88a][1]
as an example for adding it to one property:
[Magic]
public string Name { get { return _name; } set { _name = value; } }
string _name;
Another example for adding it to all the class properties:
[Magic]
public class MyViewModel: INotifyPropertyChanged
{
public string Name { get; set; }
public string LastName { get; set; }
.....
}
Some time after playing with Prism, but before I'd seem the MVVM stuff, I came up with a strategy that I still think has some validity:
I created an implementation of the ICommand interface based on reflection. The constructor accepted a target object and an operation name. Using reflection, the code looked for a method with name "[operation]", property or method with name "Can[operation]" or "[operation]Enabled" and an event with name "Can[operation]Changed" or "[operation]Enabled Changed". Only the first was required, but the reflected method/property/event were wired up to a pretty basic implementation of the ICommand interface.
I then created an implementation of IValueConverter that would create an instance of the previous class, passing the value to be converted as the target object, and the parameter of the converter being the operation name.
Given the above components, I was then able to, for example, bind a button's Command property directly to the source of the operation (along with specifying the converter), and set the Button's CommandParameter property to the name of the operation. In this way, I got declarative command binding without the command source having carnal knowledge of anything WPF.
My personal opinion is that this is interesting, but I would avoid it in general.
Avoiding boiler-plate code (or code that feels like boiler plate code) has consequences. It may seem like a good idea, since you're not retyping things constantly, but in the long run, you're making it less readable and understandable.
Personally, I try to just setup good code templates to insert the boiler plate code for me, and wrap it in regions so I can hide it in the source code. The 30 seconds it takes to fill in a file with boiler plate in that case is less painful (for me) than the 2 hours I spend, two years later when I'm trying to understand the code, or worse, the two weeks somebody else spends two years later when they're trying to understand my code....
The best way in your case is Proxy or Decorator pattern I think. You can low level entities that are wrapped/decorated with UI/WPF stuff members during runtime. This is the simplest but yet efficient way to save your time and don't bother with frameworks, injections, etc.
The only thing is you will have to design some small infrastructure to wrap your entities with appropriate decorators.
I have a class with a bunch of properties that look like this:
public string Name
{
get { return _name; }
set { IsDirty = true; _name = value; }
}
It would be a lot easier if I could rely on C# 3.0 to generate the backing store for these, but is there any way to factor out the IsDirty=true; so that I can write my properties something like this and still get the same behaviour:
[MakesDirty]
public string Name { get; set; }
No. Not without writing considerably more (arcane?) code than the original version (You'd have to use reflection to check for the attribute on the property and what not.. did I mention it being 'slower').. This is the kind of duplication I can live with.
MS has the same need for raising events when a property is changed. INotifyPropertyChanged that is a vital interface for change notifications. Every implementation I've seen yet
does
set
{
_name = value;
NotifyPropertyChanged("Name");
}
If it was possible, I'd figure those smart guys at MS would already have something like that in place..
You could try setting up a code snippet to make it easy to create those.
If you really want to go that way, to modify what the code does using an attribute, there are some ways to do it and they all are related to AOP (Aspect oriented programming). Check out PostSharp, which is an aftercompiler that can modify your code in a after compilation step. For example you could set up one custom attribute for your properties (or aspect, how it is called in AOP) that injects code inside property setters, that marks your objects as dirty. If you want some examples of how this is achieved you can check out their tutorials.
But be careful with AOP and because you can just as easily create more problems using it that you're trying to solve if not used right.
There are more AOP frameworks out there some using post compilation and some using method interception mechanisms that are present in .Net, the later have some performance drawbacks compared to the first.
No, when you use automatic properties you don't have any control over the implementation. The best option is to use a templating tool, code snippets or create a private SetValue<T>(ref T backingField, T value) which encapsulates the setter logic.
private void SetValue<T>(ref T backingField, T value)
{
if (backingField != value)
{
backingField = value;
IsDirty = true;
}
}
public string Name
{
get
{
return _name;
}
set
{
SetValue(ref _name, value);
}
}
The other alternative might be a code generator such as codesmith to automate creating the properties. This would be especially useful if the properties you are creating are columns in a database table
I can recommend to use Enterprise Library for that purpose. Policy Application Block delivers the infrastructure to do "something" (something = you can code that on your own) whenever you enter/exit a method for example. You can control the behavior with attributes. Take that as a hint an go into detail with the documentation of enterprise library.
There's a DefaultValueAttribute that can be assigned to a property, this is mainly used by the designer tools so they can indicate when a property has been changed, but, it might be a "tidy" way of describing what the default value for a property is, and thus being able to identify if it's changed.
You'd need to use Reflection to identify property changes - which isn't actually that expensive unless you're doing lots of it!
Caveat: You wouldn't be able to tell if a property had been changed BACK from a non-default value to the default one.
I'd say that the best way of solving this is to use Aspect-Oriented Programming (AOP). Mats Helander did a write up on this on InfoQ. The article is a bit messy, but it's possible to follow.
There are a number of different products that does AOP in the .NET space, i recommend PostSharp.
If you do go with Attributes, I'm fairly certain you'll have to roll your own logic to deduce what they mean and what to do about them. Whatever is using your custom class objects will have to have a way of performing these attribute actions/checks, preferably at instantiation.
Otherwise, you're looking at using maybe events. You'd still have to add the event to every set method, but the benefit there would be you're not hard-coding what to do about dirty sets on every property and can control, in one place, what is to be done. That would, at the very least, introduce a bit more code re-use.
ContextBound object. If you create a class that extends context bound object and you create a ContextAttribute you can intercept the calls made to such a property and set the IsDirty. .NET will create a proxy to your class so all calls go over something like a remoting sink.
The problem with such an approach though is that your proxy will only be invoked when called externally. I'll give you an example.
class A
{
[Foo]
public int Property1{get; set;}
public int Property2{get {return variable;} set{ Property1 = value; variable = value; }
}
When property1 is called from another class, your proxy would be invoked. But if another class calls property2, even though the set of property2 will call into property1 no proxy will be invoked, (a proxy isn't necessary when you're in the class itself).
There is a lot of sample code out there of using ContextBoundObjects, look into it.