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

Question

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?

Iceboat

how do you propose to take advantage of the existence of these constants? – Stipitate

Imagine something like: DataFieldName="<%=StudentCollection.StudentCountPropertyName %>" – Iceboat

Answer 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.

Hodgkin

how secure is it if property gets inlined? – Grecism

@ValentinKuzub: Inlining doesn't change the semantics of a method, so it's impossible that it could reduce the security or the accessibility of an object. Inlining is strictly a JIT optimization, not something you should be at all concerned about as a programmer. – Drop

if property is inlined reflection based property name resolution would fail, thats my concern – Grecism

@Valentin - if property is inlined reflection based property name resolution would fail - are you sure? I don't think IL optimisation would impact reflection. – Hodgkin

well inline property IL optimization means that all uses of int CountPropName{get{return m_Count;}} property are replaced by 'return m_Count;' as you can see CountPropName will be completely gone from optimized assembly , if such optimization takes place. Can you guarantee that your properties won't be inlined? – Grecism

@Valentin - I don't think this is how property inlining works. I always though that it is the call to the property that get's inlined, not the definition itself, so var a = new MyClass().Property; becomes var a = new MyClass().m_property;. I think I will ask a separate question. – Hodgkin

@Valentin - #6692323 – Hodgkin

indeed your right. if you dont try to get property name using reflection from inside property, inlining will not remove property metadata, and your method will be secure – Grecism

Answer 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.

Overhand

Answer 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

Hawaii

Answer 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 ;))

Gadgeteer

Answer 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.

Stipitate

Then again, constants aren't meant to change, like ever. Changing public constant breaks binary compatibility – Lactoscope

Very true but this is only relevant when shipping 'published' assemblies, i.e. for use by a third party, who may or may not re-compile their code after dropping in a new version of your assembly. For internal use assemblies, changing a constant can be feasible. I agree, however, that it is still somewhat a misuse of the concept of a 'constant'. – Stipitate

Answer 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:

• http://msdn.microsoft.com/en-us/library/a65txexh(v=VS.100).aspx

Slope