2

すべてのドメイン オブジェクトの Id 属性に文字列型を使用しています。例えば：

public class Person {
    property string Id { get; set; }
    // ... more properties
}

ここにはトリックはありません。nullは「値のない」値を表し、新しい Person が作成されて永続化される前にId残りnullます。

現在、「値のない」スペースを強化しnull、空の文字列と空白文字列はすべて「値のない」値であると言う議論があります。

つまり、実行する代わりにエンティティが新しいかどうかを確認するにはif (person.Id == null):if (string.IsNullOrWhiteSpace(person.Id))

私の謙虚な意見では、これは匂いまたは設計原則の違反ですが、どちらが原因かわかりません.

質問:この決定が違反している設計原則 (存在するnull場合) はどれですか?

(オッカムのかみそりの原理、エントロピー、または KISS に似たものであるべきだと思いますが、よくわかりません)

4

2 に答える 2

1

私は手足に出て、両方nullを定義""し、アプリケーションの空の文字列として設計原則に違反せず、コードの臭いではないと言います。目的に合わせてフィールドのセマンティクスを明確に定義する必要があります。これにより、（つまり、アプリケーションでは、「値なし」nullを意味します）。""

nullとの両方の動作が正しいことを確認するテストが必要です""。

これは、すべての空の文字列を強制的にnullにするという決定もできないということではありません。それは同様に有効な決定です。「値なし」を設定したすべての場合で、実際の値がnullであることを確認するテストが必要になります。永続層がnullを予期し、nullのみが値を示さない場合は、この方法を使用することをお勧めします。

したがって、この場合、間違った決定はなく、決定だけです。

于 2012-07-25T13:54:26.650 に答える
1

KISSの原則に違反しています。null のほかに空の文字列を処理する特別な必要がない場合、なぜそれを行うのでしょうか? すべての操作で、1 つではなく 2 つの値をチェックする必要があります。DB を探索するとき、「NULL」レコードを検索するための単純な SELECT は、正当な理由もなく、やや単純ではなくなります。

もう 1 つの違反されている原則は、最小の驚きの原則です。通常、人々は NULL 値だけが NULL オブジェクトを表すと考えています。2 つの特別な値を持つ設計は、わかりにくく、「読みにくい」ものです。

これらの「第 2 カテゴリーの特殊オブジェクト」の背後にさらに何かを隠す必要がある場合は、それを明示する必要があります。それ以外の場合、空の文字列入力を処理し、システムの残りの部分と一貫性を保つために NULL として格納するのは簡単です。

編集：

また、Bob Martin の著書Clean codeで別の「原則」を見つけました。「概念ごとに 1 語」というのは、このケースに何らかの形で関連しています。空の文字列と NULL は、1 つの概念に使用される 2 つの「単語」であるため、明らかにこのガイドラインに違反しています。

于 2013-08-08T00:24:59.763 に答える