Is is a good practice to store propery names in a public constant string?

问题

In order to protect ourself from failure because of any renaming of properties (Let's say you regenerate your poco classes because you have changed some column names in the relevant Db table) is it a good practice to decalre constant strings that keep the property names inside?

public const string StudentCountPropertyName = "StudentCount";
public int StudentCount {get;set;}

For example: Think about a DataBinding; where you type the property name in the DataFieldName attribute explicitly.

Or this is not a good idea and there is a better and still safer way?

回答1:

It is always a good idea IMHO to move any 'magic strings' to constants.

You could consider using lambda expressions to 'pick' your properties, for example:

GetDataFieldName(studentCollection => studentCollection.Count)

You will have to implement GetDataFieldName yourself, using a bit of reflection. You can look at HtmlHelperExtensions from MVC to see how it can be done. This will be the most safe approach, which gives you compile-time errors when something goes wrong and allows easy property renaming using existing refactoring tools.

回答2:

From one point of view: if you using this property name multiple times it is good practice. It will help for sure with the refactoring and when you for example change property name you see that you need change this const also.

From another point of view i guess it will be ugly when my class with 10 properties will have 10 additional consts. Another solution if you want avoid consts or explicit name typing can be getting property names through the reflection.

Use such approach or not you should decide yourself.

回答3:

I think it's a common practice to put this "magical string" or "magical numbers" in some kind of strong typed store.

Something you can consider is to code it in a Aspect Orientied Way.

For example the calls to notifypropertychagned can be realized with an attribute implemented with an aop framework, like PostSharp .

[NotifyChange]
public int Value {get;private set}

This tools also have some downsides but i think there are scenarios where they can save you a lot of work

回答4:

I do not know if I fully understand your question, but if I understand it right I would have used an attribute for that, an example could be the use of ColumnAttribute in Linq which you use to map a property to a specific column in a database (http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.columnattribute.dbtype.aspx), like in this example:

[Column(Storage="ProductID", DbType="VarChar(150)", CanBeNull=False)]
public string Id { get; set; }

And I would never use DataFieldName, I would DataBind to the strongly typed objects (and of course also make an interface to the class that uses the property above so I easily can change the implementation in the future ;))

回答5:

I suppose if the names are used in many places then it would be easier just to change them in this one place and use the constant as described in your comment.

However, a change to a database column name and object property name implies a change to your conceptual data model. How often do you think this is going to happen? In the early stages of a project, whilst conceptual modelling and implementation are paralellised across a dev team, this may be quite fluid, but once the initial conceptual modelling is done (whether this in a formalised conscious manner or just organically), it's usually quite unlikely that fundamental things like these are going to change. For this reason I think it's relatively unusual to have do this and the technique will only be productive in edge cases.

回答6:

Absolutely. It's a good idea.

By the way, I would argue that these kind of things could be better stored in application settings, because you can define such things in an application configuration file later by overriding these settings.

Doing that this way you'll avoid re-compiling if some database, POCO or whatever changes, and as in newer Visual Studio versions like 2010, you can tell it to generate settings with "public" accessibility, you can share strongly-typed settings with any assembly that reference the one containing them.

At the end of the day, I'd change your code with DataBindingSettings.StudentCountPropertyName instead of a constant.

Easy to manage, more re-usable, and readable, as "you configure a data-binding with its settings".

Check this MSDN article to learn more about application settings: