以下是共享相同标识符的类和属性的一些示例:
public Coordinates Coordinates { get; set; }
public Country Country { get; set; }
public Article Article { get; set; }
public Color Color { get; set; }
public Address Address { get; set; }
public Category Category { get; set; }
将POCO与实体框架一起使用时会更频繁地发生此问题,因为实体框架使用关系的属性名称。
那该怎么办?使用非标准类名?
public ClsCoordinates Coordinates { get; set; }
public ClsCountry Country { get; set; }
public ClsArticle Article { get; set; }
public ClsColor Color { get; set; }
public ClsAddress Address { get; set; }
public ClsCategory Category { get; set; }
育
或使用更具描述性的属性名称?
public Coordinates GeographicCoordinates { get; set; }
public Country GeographicCountry { get; set; }
public Article WebArticle { get; set; }
public Color BackgroundColor { get; set; }
public Address HomeAddress { get; set; }
public Category ProductCategory { get; set; }
不太理想,但我想可以忍受它。
还是刚刚与它生活在一起?
您最佳做法是什么?
答案 0 :(得分:6)
这有时被称为“颜色”问题 - 我的建议只是与它一起生活。
C#语言规范专为此而设计,不是问题。来自C#3规范的第7.5.4.1节:
在表单E.I的成员访问中,如果 E是单个标识符,如果是 E作为简单名称的含义(§7.5.2) 是一个常数,领域,财产,本地 变量或具有相同的参数 键入E作为a的含义 type-name(§3.8),然后都是可能的 E的含义是允许的。他们俩 E.I的可能意义永远不会 暧昧,因为我必须是 两种情况下都是E类的成员。 换句话说,这个规则很简单 允许访问静态成员 和嵌套类型的E所在的地方 否则编译时错误 已经发生了。
(后跟一个例子。)
显然,当可以提供更具描述性的属性名称时,这很好 - 但通常最好的名称 与属性相同。
这在框架本身中发生 - 例如,HttpWebRequest.CookieContainer
的类型为CookieContainer
,并且存在各种类型Evidence
Evidence
类型的属性。
答案 1 :(得分:3)
我尝试使用更具描述性的属性名称。
更改类名感觉就像是在破坏目的,因为大多数开发人员倾向于强调使用良好的描述性变量/属性名称。
如在您的示例中,例如地址可以
public Address HomeAddress { get; set; }
public Address PostalAddress { get; set; }
public Address CompanyAddress { get; set; }
等。你可以看到我的目的地。
答案 2 :(得分:2)
如果名称真的适用,我个人并不羞于让类名和属性名匹配。例如,在Address类上,具有名为Country
的属性,其类型为名为Country
的类是有意义的,并且实际上没有任何非冗余属性的名称。我尝试使用描述性属性名称来避免冲突,但有时属性的名称及其类型是使用的最佳名称,使用其他任何东西都会降低清晰度而不是改进它。
我强烈建议不要在课堂上使用类似匈牙利语的前缀。这简直太难了。
答案 3 :(得分:1)
我认为财产的名称应该只是描述它的含义。当它是Apple时,只需将其命名为Apple。
为什么任何人,只是为了财产可读性,在班级名称上使用匈牙利人。它降低了类名可读性。
访问Property时,您可以使用This关键字来防止自己误将属性误读为类:
class Food
{
public Apple Apple
{
get;
set;
}
public void DoIt()
{
this.Apple = new Apple();
}
}
class Apple
{
}
参见StyleCop的SA1101“验证对本地成员的呼叫是否以'this'为前缀。符号“