Проверка на стороне клиента (проверка на уровнях презентации)

Кончик

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать PDF

Даже если источником истины является модель домена, и в конечном счете необходимо выполнить проверку на уровне модели домена, проверка по-прежнему может обрабатываться как на уровне модели домена (на стороне сервера), так и в пользовательском интерфейсе (на стороне клиента).

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

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

Даже при использовании проверки на стороне клиента всегда следует проверять команды или входные DTOS в коде сервера, так как API-интерфейсы сервера являются возможным вектором атаки. Как правило, это ваш лучший вариант, так как если у вас есть клиентское приложение, с точки зрения пользовательского интерфейса, лучше всего быть упреждающим и не разрешать пользователю вводить недопустимые сведения.

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

Реализация проверки на стороне клиента зависит от того, какой тип клиентского приложения вы создаете. Это будет отличаться, если вы проверяете данные в веб-приложении MVC с большинством кода в .NET и веб-приложении SPA с кодом проверки в JavaScript или TypeScript.

Дополнительные ресурсы

Проверка в приложениях ASP.NET Core

• Рик Андерсон. Добавление проверки
  https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation

Проверка в веб-приложениях SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

• проверка формы
  https://angular.io/guide/form-validation

• Ратификация. Документация по Breeze.
  https://breeze.github.io/doc-js/validation.html

• ASP.NET Основные формы Blazor и входные компоненты \ </aspnet/core/blazor/forms-and-input-components>

В целом, это наиболее важные понятия в отношении проверки:

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

• Если вы считаете, что сущность должна ввести недопустимое состояние, рассмотрите возможность использования другой объектной модели, например с помощью временного DTO до создания конечной сущности домена.

• Если необходимо создать несколько связанных объектов, таких как агрегат, и они действительны только после их создания, рассмотрите возможность использования шаблона фабрики.

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

предыдущийследующий