Проверка формы MVC Asp.net

Question

Я не знаю, задавали ли люди этот вопрос или они не видели этой проблемы или чего-то еще.

Я создаю представление типа Strongly для каждого представления Create.

Я проверяю форму на стороне сервера, создав частичный класс сущностей класса LINQ.

Добавляя функцию Like

public IEnumerable<RuleViolation> GetRuleViolations()
    {
        if (String.IsNullOrEmpty(Name))
            yield return new RuleViolation("Name is Required", "Name");
        if (String.IsNullOrEmpty(Date.ToString()))
            yield return new RuleViolation("Date is Required", "Date");
        yield break;
    }

Действие моего контроллера структурировано как
_{(источник: scottgu.com )}

Задача :

Если длина поля имени равна Varchar2 (10), а пользователь вводит имя, превышающее этот предел, тогда объект продукта (см. Изображение) будет иметь имя Пустая строка.

Более того, другие проблемы такие же, как указано выше, например date Если пользователь не введет Date, то у объекта также будет дата, например, 1/1/0001.

Резюме: должны ли мы использовать этот метод? Или использовать метод, как получить все элементы с помощью FormColletion или Request.Form ...

Кэм, ты дашь мне лучшее предложение?

Также см. пост Джастина Этефриджа

Answer 1

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

В этом сервисном слое вы должны реализовать свои правила, такие как длина имени, срок действия даты, что разрешено и не разрешено. Если там что-то не так, вы можете вспомнить ошибки и заставить контроллер разобраться с ними.

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

Я посмотрю, смогу ли я привести пример в ближайшее время (что-то происходит в данный момент ...)

Answer 2

Существует множество возможных решений этой проблемы.

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

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

• Для логических значений (значение по умолчанию - false): проверить, что у провайдера значений есть попытка ввести значение для поля в дополнение к проверке самой сущности. Кроме того, вы можете сделать столбец обнуляемым и убедиться, что он не нулевой. Оба являются компромиссами, но последний делает модель данных соответствующей структуре валидации, поэтому я предпочитаю первый.