hpjchobbes Ответов: 1

Проверка поля столбца/строки Datatable

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

Строковое поле меньше или равно X (x может изменяться в зависимости от столбца данных)
Строковое поле содержит ':', и каждая строка между двоеточием меньше или равна X, а вся строка меньше Y
Строковое поле не может начинаться с числа
Длина комбинации трех полей в строке данных не может быть больше X символов.
Поле даты должно находиться между датами X и Y
Двойное поле максимум X десятичных знаков

Так, например, EmployeeRow может иметь строковые поля FirstName, MiddleInitial, LastName с максимальной длиной 25, 5 и 25, но с общим количеством 40 символов и полем HireDate, которое должно быть между 01/01/1901 и 12/31/2099.

Что я уже пробовал:

Я думал о создании статического класса для каждого из правил проверки, который возвращает структуру, имеющую результаты проверки (логическое значение) и строковое Сообщение (Почему проверка не удалась):
public static class ValidationRules
{
    public static ValidationResult MaxLengthValidation(this string value, int maxLength){ // }
    public static ValidationResult MultiPartMaxLengthValidation(this string value, int maxPartLength, int maxTotalLength){ // }
    public static ValidationResult DateRangeValidation(this DateTime value, DateTime minDate, DateTime maxDate) { // }
    // etc..
}


Затем я мог бы настроить свой DataRow так, чтобы у него была функция Validate, которая проверяла бы каждый из столбцов, а также реализовывала бы любую многоколоночную проверку. Но почему-то мне кажется, что это не самый лучший подход. Существуют ли какие-либо лучшие проекты или способы создания этой концепции?

1 Ответов

Рейтинг:
4

Wendelius

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

Однако только некоторые проверки могут быть выполнены с использованием ограничений, таких как обязательные, внешние ключи, проверки диапазона и т. д. Это означает, что вам также нужно кодировать различную логику проверки. Чтобы как можно скорее отреагировать на проблемы, вы можете проверить данные при изменении столбца или строки. Взгляните на Проверка данных в наборах данных[^]

Третья категория является более сложной, особенно круговая проверка, которая не может быть применена все время. В середине модификации у вас может возникнуть недопустимая ситуация, но в конце концов вы должны предотвратить ввод таких данных в систему. Это означает, что вам также может потребоваться выполнить отдельную проверку перед сохранением/фиксацией изменений. Этот вид проверки обычно должен запускаться только тогда, когда изменения сохраняются, поэтому он часто требует информации из-за пределов таблицы данных (или набора). Например, вам может потребоваться запустить эту проверку только при нажатии кнопки Сохранить или в какой-либо аналогичной ситуации.

hpjchobbes

В зависимости от того, как пользователь собирается использовать мое программное обеспечение, он должен иметь возможность хранить «недействительные» данные в таблице данных, но при этом иметь возможность выделять недопустимые данные, чтобы у пользователя была возможность исправить информацию. Данные будут сохранены, когда пользователь нажмет кнопку сохранения, что произойдет после того, как пользователь предположительно исправит какие-либо недопустимые данные. Также есть несколько параметров для автоматического исправления некоторых данных (например, обрезки слишком длинных строк). Из-за этого я, вероятно, не буду использовать большинство ограничений. Статья, которую вы связали, кажется лучшей из того, что я собираюсь получить, но начинает казаться, что мне нужно вручную создать типизированный набор данных, вместо того, чтобы позволить дизайнеру сделать это, поскольку я хочу иметь возможность создавать столбцы проверки.