valores - validar si un objeto es null c#

Acceso a la base de datos C#: DBNull vs null

Question

Tenemos nuestro propio ORM que utilizamos aquí, y ofrecemos envoltorios fuertemente tipados para todas nuestras tablas de db. También permitimos que se ejecute SQL ad hoc débilmente tipeado, pero estas consultas aún pasan por la misma clase para obtener valores de un lector de datos.

Al ajustar esa clase para trabajar con Oracle, nos hemos encontrado con una pregunta interesante. ¿Es mejor usar DBNull.Value o null? ¿Hay algún beneficio al usar DBNull.Value? Parece más "correcto" usar null, ya que nos hemos separado del mundo de DB, pero hay implicaciones (no se puede simplemente ToString() ciego cuando un valor es nulo, por ejemplo), así que definitivamente es algo que necesitamos toma una decisión consciente acerca de.

Answer 1

A partir de la experiencia que he tenido, .NET DataTables y TableAdapters funcionan mejor con DBNull. También abre algunos métodos especiales cuando está fuertemente tipado, como DataRow.IsFirstNameNull cuando está en su lugar.

Desearía poder darle una mejor respuesta técnica que eso, pero para mí el resultado final es usar DBNull cuando trabajo con los objetos relacionados con la base de datos y luego usar un nulo "estándar" cuando trato con objetos y un código relacionado con .NET.

Answer 2

Me parece mejor usar null, en lugar de DB null.

La razón es porque, como dijiste, te estás separando del mundo DB.

En general, es una buena práctica verificar los tipos de referencia para asegurarse de que no sean nulos de todos modos. Comprobará nulo para otras cosas que no sean datos de BD, y creo que es mejor mantener la coherencia en todo el sistema y usar null, no DBNull .

A largo plazo, arquitectónicamente, creo que es la mejor solución.

Answer 3

Si ha escrito su propio ORM, entonces diría que simplemente use nulo, ya que puede usarlo como quiera. Creo que DBNull se usó originalmente solo para evitar el hecho de que los tipos de valor (int, DateTime, etc.) no podían ser nulos, por lo que en lugar de devolver algún valor como cero o DateTime.Min, lo que implicaría un nulo (malo, malo ), crearon DBNull para indicar esto. Tal vez había algo más, pero siempre supuse que esa era la razón. Sin embargo, ahora que tenemos tipos anulables en C # 3.0, DBNull ya no es necesario. De hecho, LINQ to SQL solo usa null en todo el lugar. No hay problema. Abraza el futuro ... usa null. ;-)

Answer 4

Use DBNull .
Buscamos algún tipo de problema cuando usamos null.
Si recuerdo correctamente, no puede INSERTAR un valor nulo en un campo, solo DBNull.
Podría estar relacionado con Oracle solo, lo siento, ya no sé los detalles.