¿Cómo resolvemos todo esto? ¿La conversión de tipo DBNull a tipo Cadena no es válida? ¿Maldición?

Question

En nuestras aplicaciones, no puedo pensar en muchos casos en los que nos preocupan los campos de cadena nula. Solo queremos que se muestren como cadenas vacías en la mayoría de las situaciones.

Así que cuando utilizando el construido en conjunto de datos ADO.NET/tablas de datos, el error:

Conversion from type DBNull to type String is not valid

es demasiado común más adelante en la aplicación cuando se hace referencia a ningún dato de cadena de edad.

Es un problema particular porque puede atrapar tan fácilmente (y con frecuencia no se ve en las pruebas)

Sé que hay varias soluciones:

1. Comprobar si .IsXXXNull en todos los casos

Pero:

• que es un proceso tedioso pocas líneas adicionales de código de aplicación en todo el

• si olvidamos el cheque, ni siquiera el 1 vez en 100, tenemos un error potencial al acecho

2. En el diseñador de conjunto de datos, cambie el NullValue propiedad del campo de la opción predeterminada "excepción throw" a "vacío"

Pero:

• tenemos que identificar y cambiar cada mesa y cada campo de cadena añadimos al diseñador conjunto de datos (recuerde el valor predeterminado es "Throw Excepción")

• si olvida el cambio incluso de 1 vez en 100 , tenemos un error potencial acecho

3. evitar el almacenamiento de valores nulos en los datos de base

Pero

:

• Tenemos que identificar y cambiar cada mesa y cada campo de cadena añadimos a la base de datos

• que no siempre tenemos ese tipo de control sobre los datos de base

4.No utilice el diseñador conjunto de datos, extraer datos en nuestros propios objetos de clase, frente a todo el desorden DBNull en nuestro propio código

Pero:

• sí, tenemos que hacer para nuestro "mayor" tablas. pero el diseñador conjunto de datos es una buena manera , rápida para tirar en una lista de selección o tabla de búsqueda, en la que en realidad sólo necesitamos el comportamiento predeterminado de datos

5. El uso de un generador de código o el Marco como lugar de CSLA conjuntos de datos

Pero:

• gran paso para resolver un pequeño problema ... la segunda respuesta para la parte superior alineado en cuestión SO etiquetada CSLA menciona: "es contras son que tiene un poco de col curva de ganancia ".

Answer 1

Esta es la razón por conjuntos de datos y tablas de datos son:

1. Buena para poner rápidamente en conjunto una aplicación que utiliza el acceso de datos simple (como usted menciona).

2. No es bueno para una aplicación empresarial bien diseñada; hay demasiadas simplificaciones y generalizaciones.

He encontrado que el uso de un modelo de objetos conscientes de enlace de datos adecuada casi siempre triunfa sobre el uso de bases de datos y tablas de datos, y pueden tener todo (y más!) La funcionalidad, facilidad de uso y velocidad de usando DataSets y DataTables.

Y no se encuentra con problemas como estos, ya que su modelo de negocio no está estrechamente vinculado a la estructura de su base de datos.

Todavía tengo que conocer a alguien que ha usado un framework como CSLA.NET y quería volver a DataSets y DataTables.

Answer 2

5. (o tal vez 4b)

usen una estructura que proporciona la funcionalidad NULL para usted en su clase de acceso a datos. El marco CSLA.NET mencionado anteriormente (por Riko) utiliza una clase SafeDataReader, que funciona exactamente como un DataReader, pero puede convertir todos los valores NULL en valores vacíos para sus capas de acceso de datos y lógica de negocios.