Sollte ich meine Objekteigenschaften auf Null setzen oder die CLR-Standardwerte für jeden Typ verwenden?

Je nach Ihrer Domain können Sie verschiedene Ansätze kombinieren.

Für einige Attribute kann es sinnvoll sein, null -Werte zu haben, wie in "nicht gesetzt".

In Ihrem Beispiel hat vielleicht ein Modell nicht ein Id , bevor es in der Datenbank beibehalten wird. Wenn dies der Fall ist und ein id-less-Modell im Hinblick auf die Geschäftslogik sinnvoll ist , ist ein NULL-Wert Id besser als Id = 0 . Wenn Ihre Anwendung jedoch nie mit id-less-Modellen arbeitet und normalerweise Id für etwas gleichwertig hält, wäre es verrückt,

jedes Mal, wenn Sie etwas damit machen wollen.

In diesem Fall sollten Sie standardmäßig mit Id = 0 arbeiten.
Sie könnten auch eine Konstante einführen (wie ich oben getan habe), obwohl ich es für nichts anderes als IDs empfehlen würde, und nur für den Fall, dass sie von Code anderswo stark verwendet werden.

Auch hier kommt es auf die Domain an.
Ihre Aufgabe besteht darin, sicherzustellen, dass Objekte, die gegen Geschäftsregeln verstoßen, nicht einfach erstellt werden können.

  

Was ist der akzeptierte Weg, damit umzugehen?

Akzeptiert? Es hängt von der Domäne ab.

  

Wenn ein money-Wert auf null gesetzt ist, wissen Sie, dass er nicht festgelegt wurde.

Nicht unbedingt. Stellen Sie sich vor, ich verwende eine Banking-Anwendung, und ich möchte nach einer bestimmten Transaktion suchen, und ich bekomme einen Dialog, der so aussieht:

Jetzt sollte TransactionSearchParameters.Amount auf null gesetzt werden. Sie können dies nicht davon unterscheiden, dass es nicht eingestellt ist.

  

Wenn Sie mit der Datenbank arbeiten, ist es außerdem einfach zu wissen, ob Sie einen Nullwert in ein Feld schreiben müssen oder ob Sie herausfinden wollen, ob es null ist oder nicht.

Sie sollten mehr Zeit damit verbringen, Ihre Domäne richtig zu modellieren, und dann ein ORM herausfinden, wie Sie dieses Zeug richtig in die Datenbank bringen können.

Nur eine Idee hier hinzuzufügen, es gibt immer das Null-Objektmuster für komplexe Typen, wenn es angemessen ist benutzen.

Es hängt davon ab, wie Sie Ihren Code verwenden werden. Wenn die Eigenschaften einfache Typen wie Integers & amp; Zeichenfolgen, Standardwerte sind besser, wenn die Eigenschaften selbst Objekte sind, habe ich Nullen verwendet, weil in C # / Java / PHP Objektverweise wirklich Objektzeiger sind und besser zu verwenden sind.

Wenn es sich jedoch bei Ihren Eigenschaften um Sammlungen handelt, z. B. Listen oder Karten, ist es eine "bessere Vorgehensweise", die Sammlung zu erstellen und sie leer anstatt null zu lassen.

Prost.

Nun ... die beste Antwort (sehr eigenwillig dort, aber ich habe das Recht) ist, wenn Sie nicht zwischen den beiden unterscheiden müssen, weil es nur einen möglichen Zustand gibt, nämlich dass es gültig ist:

Ich weiß, dass das nicht immer möglich ist, zum Beispiel Query by Example.

Die Verwendung von "magischen Zahlen" wie zB "Einstellung eines ID-Wertes auf 0 ist sinnvoll ..." wird generell vermieden. Sobald du das getan hast, muss jeder Code, den du schreibst, codiert werden, um zu wissen, was diese magische Zahl ist und was sie bedeuten. Dies wird selten erreicht und ist voller bösartig aussehender und fehleranfälliger Code.

Wenn Sie einfach MÜSSEN die Unterscheidung zwischen einem Feld mit einem Wert und nicht haben, ist Ihr späteres Beispiel ein wenig besser. Zumindest hier sind deine Werttypen explizit gültig oder ungültig. Verwenden von Nullable & lt; T & gt; bedeutet, dass Sie eine andere Methode verwenden müssen, um zu bestimmen, ob eine Klasse, eine Zeichenfolge oder ein anderer Referenztyp ungültig ist.

IMO, Sie sind besser dran mit dem folgenden, obwohl es sehr ausführlich wird, wie Sie sehen werden.

Schließlich, wenn Sie diese Route gehen, wird ein Code-Generator Ihnen gut dienen.