Mejor DateTime? o use el valor predeterminado (DateTime) para NULL?

Question

Estoy diseñando un sitio web C#/NHibernate que cuenta con un sistema de mensajería privado. Me gustaría que los administradores verifiquen si un usuario ha leído un mensaje y cuándo, y juntos resaltan los mensajes que aún no han sido leídos por los usuarios. Para obtener a la vez, me encontré con dos opciones:

Opción 1

class Message 
{ 
    DateTime? Read; 
} 

donde Read==null significa no leído todavía

Opción 2

class Message 
{ 
    DateTime Read; 
} 

donde Read==default(DateTime) (Enero 1º 1 dC, 0 : 00: 00) significa que aún no se ha leído.

En la universidad, me han enseñado a utilizar el valor NULL para manejar todas especiales casos, y también utilizando el anulable tipo parece una buena opción ya que parece más fácil para consultar los mensajes no leídos comprobando si son NULL o no.

Pero, el uso de tipos de nullable al menos implica boxeo y unboxing en el código, con un rendimiento decreciente. Por otro lado, la consulta de los mensajes no leídos significa comparar el valor (pero puede ser indexado)

Mi pregunta es

¿Cuál es su enfoque sugerido para esto? ¿Qué mejores prácticas sugieren en este caso?

Answer 1

Utilice DateTime?. Su propósito específico es evitar el uso de valores reservados (también conocidos como "números mágicos") para representar casos especiales, como null.

Además, el uso de un tipo nullable no introduce boxeo. Cualquier valor que haya sido encuadrado será, pero no introducirá ningún boxeo simplemente cambiando. El tipo Nullable<T> es en realidad una estructura, y la capacidad de comparar con null (o Nothing en VB.NET) es estrictamente una convención de lenguaje. Debajo de las portadas, se traduce en un cheque en la propiedad HasValue.

Answer 2

El uso de tipos anulables no "disminuye significativamente el rendimiento" en comparación con enfoques alternativos. Ambos DateTime y DateTime? son estructuras y no hay boxeo involucrado aquí. Usar una nullable es la elección correcta.

Answer 3

Como dijeron Mark y Adam, un tipo que admite nulo es el camino a seguir. No verá un golpe de rendimiento y hará que las consultas sean mucho más simples.

Answer 4

Para aprovechar lo que dijo Mark, si le preocupaba el uso de un tipo anulable en el código del cliente, podría establecerlo en DateTime.MinValue y luego en una capa de negocios, cambiar a un valor nulo. Luego puede alimentar el tipo que admite nulos para su DataAccess. Esto ayuda a mantener una capa de abstarction para usar nulables.

Answer 5

Hágase la misma pregunta cuando se trata de valores numéricos. ¿Uso 0? ¿Qué pasa si 0 tiene un significado real? NULL es la ausencia de valor. 99 de cada 100 veces, vaya con lo que hace que la intención del código sea más evidente. En cuanto al rendimiento, incluso si lo hay, palidecerá en comparación con los problemas de rendimiento que tenga su propio código.

Answer 6

¿Falta un truco?

class Message 
{ 
    DateTime LastRead; 
    bool Read; 
}