Question

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

private SalesOrder salesOrder;

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

或者我应该总是使用Object或BusinessObject附加object属性来区分属性类型和属性本身：

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

如果属性是网页或对象的一部分，这是否重要？

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;}
}

总之，接近它的方法是：

这个类的最佳名称是什么，它将其与其他类所做的区分开来（因此，没有“对象”，“业务对象”，“实体”或类似的名称，除非它真正脱颖而出，特别相关在给定的情况下）。
该物业反映的最佳名称是什么，将其与其他物业区分开来。

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

Answer 2

不要在名称中添加类型。课程可以在他们的一生中改变意义，你不希望你的代码增长，但不能反映已经发生的变化。这是ASP时代的暂停状态，因为您曾经使用＆＃39; tbl＆＃39;和＆＃39; vw＆＃39;。将属性命名为单数或复数，并且保持一致。只是不要把这个类放在名字中。如果您希望更准确地反映对象是什么，请查看域驱动设计，以便您的代码反映业务而不是程序员认为的业务。

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

2 个答案: