Автоматическое дублирование бизнес-логики в веб-клиенте

Question

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

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

Какие могут быть способы дублирования проверки на стороне сервера на стороне клиента? Используя механизм правил и применяя идентичные правила, применяемые двумя доверенными механизмами правил на каждой стороне, фактически делегирование проверки сервера, выполняемой JavaScript, который затем регистрируется в визуализированном клиенте, кажется еще одним вариантом, но кажется сложным.

Есть идеи по этому скорее академическому, чем практическому вопросу?

Answer 1

Контроль проверки ASP.NET может сделать это.

Элементы управления проверкой ASP.NET также предоставляют два способа проверки: на стороне сервера или на стороне клиента. Хорошая вещь об этих элементах управления Validation заключается в том, что он будет предварительно проверять клиентскую проверку, когда обнаружит, что браузер может (если проверка клиентской стороны не была отключена). Таким образом сокращая туда и обратно. И это преформирует серверную часть, где это необходимо. Это обнаружение и проверка на стороне клиента / сервера выполняется разработчиком без лишних усилий!

http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=46

В противном случае вам придется следовать той же модели. Создайте набор правил, затем внедрите каждое из них с обеих сторон (если возможно, в элементах управления). Затем позвольте разработчику выбрать, какое правило применять к каким элементам управления html.

Answer 2

Ну, вы никогда не сможете автоматически дублировать код проверки на стороне сервера в клиенте, потому что

1. языки (javascript и C #) слишком разные
2. в коде на стороне сервера часто имеются данные, которых нет в клиенте

Однако вполне возможно полностью удалить код проверки на сервер. Конечно, по тем же двум причинам, это лучшее место для такого кода. Используя методы Ajax и объект WebRequest, короткая заглушка проверки в клиенте может довольно легко вызвать функцию проверки на стороне сервера без необходимости обратной передачи.

Answer 3

Хорошей практикой является то, что системная запись должна иметь проверку, чтобы убедиться, что согласованность поддерживается. Итак, в вашем сценарии вход вашей системы - это серверная часть веб-приложения. Таким образом, вы должны иметь подтверждение на этой стороне. Позвольте мне привести вам пример, скажем, я создаю инструменты автоматизации, которые отправляют данные в ваше веб-приложение, и тогда пользовательский интерфейс не задействуется, тем не менее, если инструмент не предоставляет firstName, он не сможет записать данные.

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

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

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

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

Answer 4

См .: Проверка MVC - СУХОЙ с сервисным уровнем - Какова лучшая практика?

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

Answer 5

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

Все остальное потребует дополнительных обращений к серверу (чтобы выполнить всю проверку в C #) или заставить сервер выполнять JavaScript (что, я считаю, гораздо сложнее, чем внедрение механизма правил).

Единственная альтернатива - дублирование кода (как это делает Microsoft).

Answer 6

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

В мире .NET это можно сделать, просто написав код проверки в качестве веб-службы. AJAX-клиенты и само серверное приложение будут вызывать методы в этом веб-сервисе для проверки (примечание: это может быть плохой идеей с точки зрения безопасности - я не знаю).