5

たとえば、これは良い習慣ですか？

private SalesOrder salesOrder;

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

または、常にオブジェクト プロパティに Object または BusinessObject を追加して、プロパティ タイプとプロパティ自体を区別する必要があります。

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

プロパティが Web ページまたはオブジェクトの一部であるかどうかは重要ですか?

4

2 に答える 2

2

後者は恐ろしいです。これは、販売注文を持つものをモデル化しており、それはオブジェクトによってモデル化されています。販売注文オブジェクトを持つものをモデル化するのではありません。

「BusinessObject」は、開発者がビジネスオブジェクトを処理するのを支援するツールを作成している場合は、コード内の何かの名前のみにする必要があります。

前者はしばしば良いです。

複数存在する可能性がある場合は良くありませんSalesOrder。1つが「メイン」であっても、混乱を招きます。ただし、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

名前に型を入れないでください。クラスはその存続期間中に意味を変更する可能性があり、変更内容を反映せずにコードを拡張することは望ましくありません。これは、テーブル名に 'tbl' を、ビューに 'vw' をプレフィックスとして使用していた ASP 時代からの持ち越しです。単数または複数のプロパティに名前を付け、一貫性を保ちます。クラスが何であるかを名前に入れないでください。また、オブジェクトが何であるかをより正確に反映したい場合は、ドメイン駆動設計を調べて、プログラマーが考えるものではなくビジネスをコードに反映させます。

于 2012-08-24T14:55:53.457 に答える