将属性名称存储在公共常量字符串中是一个好习惯吗？
为了保护我们自己免受因属性重命名而导致的失败（假设您重新生成了 poco 类，因为您更改了相关 Db 表中的某些列名称），将属性名称保留在内部的常量字符串是一个好习惯吗？
public const string StudentCountPropertyName = "StudentCount";
public int StudentCount {get;set;}
例如：考虑一个数据绑定；您可以在 DataFieldName 属性中显式键入属性名称。
或者这不是一个好主意，有更好、更安全的方法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
恕我直言，将任何“魔术字符串”移至常量始终是一个好主意。
您可以考虑使用 lambda 表达式来“选择”您的属性，例如：
您必须使用一些反射自己实现
GetDataFieldName。您可以查看 MVC 中的HtmlHelperExtensions以了解如何完成它。这将是最安全的方法，当出现问题时，它会给您带来编译时错误，并允许使用现有的重构工具轻松地重命名属性。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:
You will have to implement
GetDataFieldNameyourself, using a bit of reflection. You can look atHtmlHelperExtensionsfrom 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.从一个角度来看：如果多次使用此属性名称，这是一种很好的做法。它肯定会对重构有所帮助，例如当您更改属性名称时，您会发现您也需要更改此常量。
从另一个角度来看，我想当我的具有 10 个属性的类将有 10 个额外的常量时，这将是丑陋的。如果您想避免 const 或显式名称键入，另一个解决方案可以是通过反射获取属性名称。
使用或不使用这种方法你应该自己决定。
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.
我认为将这个“神奇的字符串”或“神奇的数字”放入某种强类型存储中是一种常见的做法。
您可以考虑以面向方面的方式对其进行编码。
例如，对notifypropertychagned的调用可以通过aop框架实现的属性来实现，例如 PostSharp 。
这个工具也有一些缺点，但我认为在某些情况下它们可以为您节省大量工作
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 .
This tools also have some downsides but i think there are scenarios where they can save you a lot of work
我不知道我是否完全理解你的问题，但如果我理解正确的话，我会为此使用一个属性，一个例子可以是在 Linq 中使用 ColumnAttribute，您可以使用它将属性映射到数据库中的特定列（http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.columnattribute.dbtype.aspx），就像在这个例子中一样：
我永远不会使用DataFieldName，我会将DataBind强烈地类型化对象（当然，还为使用上面属性的类创建一个接口，这样我将来就可以轻松更改实现；））
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:
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 ;))
我想如果这些名称在很多地方使用，那么在这一处更改它们并使用评论中描述的常量会更容易。
但是，对数据库列名称和对象属性名称的更改意味着对概念数据模型的更改。您认为这种情况会发生多少次？在项目的早期阶段，虽然概念建模和实现在开发团队中并行进行，但这可能相当不稳定，但是一旦完成了初始概念建模（无论是以形式化的有意识的方式还是只是有机地），它通常会非常流畅。像这样的基本事情不太可能发生改变。出于这个原因，我认为这样做相对不寻常，并且该技术仅在边缘情况下才会有效。
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.
绝对地。这是个好主意。
顺便说一句，我认为这些东西可以更好地存储在应用程序设置中，因为您可以稍后通过覆盖这些设置来在应用程序配置文件中定义这些东西。
通过这种方式，如果某些数据库、POCO 或任何其他内容发生更改，您将避免重新编译，并且与 2010 等较新的 Visual Studio 版本一样，您可以告诉它生成具有“公共”可访问性的设置，您可以共享强类型设置与引用包含它们的程序集的任何程序集。
最终，我会使用
DataBindingSettings.StudentCountPropertyName而不是常量来更改您的代码。易于管理，更具可重用性和可读性，因为“您可以使用其设置来配置数据绑定”。
查看此 MSDN 文章以了解有关应用程序设置的更多信息：
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.StudentCountPropertyNameinstead 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: