5

例如，这是一个好习惯吗？

private SalesOrder salesOrder;

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

或者我是否应该始终将对象属性附加到 Object 或 BusinessObject 以区分属性类型和属性本身：

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

属性是网页的一部分还是对象的一部分是否重要？

4

2 回答 2

2

后者太可怕了。它是对具有销售订单的东西进行建模，而销售订单又由对象建模——而不是对具有销售订单对象的东西进行建模。

如果您正在为开发人员编写一个工具来帮助他们处理业务对象，那么“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. 该属性所反映的内容的最佳名称是什么，可以将其与其他属性区分开来。

如果他们最终在特定情况下给出相同的名称，那很好（除非它是一个嵌套类，当它模棱两可且非法时）。如果他们最终给了一个不同的名字，那也很好。

于 2012-08-24T15:04:29.427 回答
1

不要将类型放在名称中。类可以在其生命周期中改变含义，您不希望代码增长但不反映已更改的内容。这是 ASP 时代的一种保留，当时您习惯用“tbl”为表名添加前缀，用“vw”为视图添加前缀。将属性命名为单数或复数，并保持一致。只是不要把类的名字放在名字中。如果您希望更准确地反映对象是什么，请查看域驱动设计，以便您的代码反映业务而不是程序员认为的业务。

于 2012-08-24T14:55:53.457 回答