Как мы решаем все это «Неверное преобразование типа DBNull в тип String»?

Question

В наших приложениях я не могу вспомнить многих случаев, когда мы заботимся о пустых строковых полях. Мы просто хотим, чтобы они отображались как пустые строки в большинстве ситуаций.

Таким образом, при использовании встроенного набора данных ADO.NET / таблиц данных возникает ошибка:

Преобразование из типа DBNull в тип Неверная строка

слишком часто встречается позже в приложении при обращении к любым старым строковым данным.

Это особая проблема, потому что она может так легко нас поймать (и часто не замечается при тестировании)

Я знаю, что есть различные решения:

1. Проверьте на наличие .IsXXXNull во всех случаях

Но:

• это несколько утомительных лишних строк код во всем приложении

• если мы забудем чек, то даже 1 раз из 100 мы получим скрывающаяся потенциальная ошибка

2. В конструкторе набора данных измените свойство NullValue поля со значения по умолчанию «Исключение выброса» на «Пусто»

Но:

• мы должны идентифицировать и изменить каждая таблица и каждое строковое поле мы добавляем в конструктор наборов данных (помните, по умолчанию «Бросить Исключение ")

• если мы забудем об изменении хотя бы 1 раз из 100, мы получим потенциальную ошибку скрываясь

3. Избегайте хранения нулей в базе данных

Но:

• мы должны идентифицировать и изменить каждая таблица и каждое строковое поле добавляем в базу

• у нас не всегда есть такие контроль над базовыми данными

4. Не используйте конструктор наборов данных, извлекайте данные в наши собственные объекты классов, разбирайтесь со всеми беспорядками DBNull в нашем собственном коде

Но:

• да, мы делаем это для нашего "майора" столы. но дизайнер наборов данных является хороший, быстрый способ вытащить в списке выбора или справочная таблица, где мы только на самом деле нужно поведение данных по умолчанию

5. Используйте генератор кода или инфраструктуру, например CSLA, вместо DataSets

Но:

• большой шаг для решения небольшой проблемы ... во втором ответе на вопрос с наивысшим рейтингом в CSLA с тегами SO упоминается: «Минусы в том, что у него есть немного кривой обучения».

Answer 1

Вот почему DataSets и DataTables:

1. Хорошо для быстрого создания приложения, которое использует простой доступ к данным (как вы упоминаете).

2. Не хорошо для хорошо спроектированного корпоративного приложения - слишком много упрощений и обобщений.

Я обнаружил, что использование надлежащей объектной модели с поддержкой привязки данных почти всегда превосходит использование DataSets и DataTables, и они могут иметь все (и даже больше!) Функциональности, простоты использования и скорости использования DataSets и DataTables. .

И вы не столкнетесь с такими проблемами, потому что ваша бизнес-модель не тесно связана со структурой вашей базы данных.

Мне еще предстоит встретиться с кем-то, кто использовал фреймворк, такой как CSLA.NET и хотел вернуться к DataSets и DataTables.

Answer 2

5. (или, может быть, 4b)

Используйте платформу, которая обеспечивает функциональность NULL для вас в вашем классе доступа к данным. В вышеупомянутой инфраструктуре CSLA.NET (от Riko) используется класс SafeDataReader, который работает точно так же, как DataReader, но может преобразовывать все NULL в пустые значения для ваших уровней доступа к данным и бизнес-логики.