Пользовательские валидаторы в разработке ASP.NET - чистота против эффективности

Question

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

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

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

Учитывая относительно низкий уровеньактивность на сайте (в настоящее время и в будущем), вы считаете это приемлемым решением?Или вы ВСЕГДА предпочитаете проводить как можно больше проверок на клиенте, чтобы повысить скорость отклика, даже если это несколько усложнит ситуацию для тех, кто может над этим поработать в будущем?

Answer 1

Преимущество проверки на стороне клиента заключается в том, что пользователю не нужно ждать отправки страницы.

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

Если вы хотите получить скорость проверки на стороне клиента, но сохранить клиент в чистоте для обслуживания, вы можете подписать событие onblur каждого входа формы для выполнения вызова AJAX и проверки модели, а затем ограничить форму отправить, если форма недействительна. Все это может быть включено во внешний файл .js, поэтому все, что нужно сделать вашему ИТ-специалисту, это включить его, а оттуда - просто HTML.

Answer 2

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