命名对象属性的最佳实践是什么？

Question

例如，这是一种好的实践吗？

private SalesOrder salesOrder;

public SalesOrder SalesOrder
{
    get { return salesOrder; }
    set { salesOrder = value; }
}

我应该始终将对象属性与Object或BusinessObject配合使用，以区分属性类型和属性本身吗？

public SalesOrder SalesOrderBusinessObject
{
    get { return salesOrder; }
    set { salesOrder = value; }
}

属性是属于网页还是对象，这是否重要？

- Will

---

在我考虑的情况下，实际上是一个用户控件。该控件名为SendEmail.ascx。因此使用方式将会是 SendEmail.Order。 - Will

然后，您应该将UI与业务逻辑分开，创建一个名为“Sale”（或其他名称）的类。 - Tim Schmelter

SalesOrder是一个完全独立的类，具有自己的属性和数据访问方法。我使用这个属性来跟踪SalesOrder在postbacks之间的变化。 - Will

Answer 1

后者很糟糕。它建模的是一个有销售订单的东西，而这个销售订单又由一个对象来建模 - 而不是建模具有销售订单对象的东西。

如果你正在编写一个帮助开发人员处理业务对象的工具，那么“BusinessObject”应该只是你代码中某个东西的名称。

前者通常是好的。

如果可能会存在多个“SalesOrder”，即使其中一个是“主要”的，也不好，因为这会导致混淆。但是，一个可枚举或集合的“SalesOrders”属性，其中包含一些“SalesOrder”对象是好的（当英语复数形式不是单数+ 's'形式时，请使用真正的复数形式而不是仅添加s，除非这种情况下英语复数与单数相同）。

当其他所有内容都与销售有关时，它就不那么好了。例如，这很糟糕：

public class Sale
{
  public SalesOrder SalesOrder{get;set;}
  public SalesReference SalesReference{get;set;}
  public decimal SalesValue{get;set;}
  public string SalesCurrency{get;set;}
}

在这种情况下，我会从每个属性名称中删除“Sales”，但不一定从类名中删除。

然而，在这种情况下最好这样做：

public class Sale
{
  public SalesOrder SalesOrder{get;set;}
  public StockOrder StockOrder{get;set;}
}

总的来说，处理它的方法是：

1. 为这个类所做的事情取一个最好的名称，使其与其他类所做的事情有所区别（因此，在给定的情况下，不要使用“对象”，“业务对象”，“实体”或类似名称，除非它确实在特定情况下特别相关）。
2. 为属性反映的内容取一个最好的名称，使其与其他属性有所区别。

如果在特定情况下它们最终给出相同的名称，那么这很好（除非它是一个嵌套类，这时它是模糊和非法的）。如果它们最终给出不同的名称，那也没关系。

- Jon Hanna

---

该类是一个用户控件，名为SendEmail，与“SalesOrder”具有1:1的关系。 - Will

我可能会选择 SalesOrder。这个类是为了代表销售订单。属性是用来保存控件正在处理的销售订单。两个问题都暗示着答案是 "销售订单"，并且将 .NET 命名约定应用于该名称，分别在两个情况下得到 SalesOrder。如果有什么需要批评的，那就是将“发送”这个动词用于一个事物（一个控件），但这很可能是一个完全合理的缩写。 - Jon Hanna

Answer 2

不要在名称中标注类型。类别在其生命周期内可以改变含义，您不希望代码增长但不反映已更改的内容。这是ASP时代的保留用法，当时您需要使用“tbl”作为表名前缀，“vw”用于视图。将属性命名为它们所代表的单数或复数形式，并保持一致性。只是不要在名称中注明类别。如果您想更准确地反映对象是什么，请研究领域驱动设计，以便您的代码反映业务而不是程序员认为的内容。

- Josh