Керування перевірками на стороні клієнта та сервера в одному місці

Я на 100% працюю над тим, що, безумовно, слід використовувати як перевірку даних на стороні клієнта, так і на сервері.

Однак у рамках, в яких я працював, підходи, які я бачив, ніколи не бували сухими. У більшості випадків немає плану чи шаблону - перевірки записуються у специфікації моделі, а перевірки записуються у формі на поданні. (Примітка. Більшість мого досвіду з перших рук - це Rails, Sinatra та PHP w / jQuery)

Придумуючи це, схоже, було б не важко створити генератор, який, з урахуванням набору валідацій (наприклад, назва моделі, поля (и), умова), міг би створити необхідний матеріал на стороні клієнта та на сервері. Крім того, такий інструмент може приймати перевірки на стороні сервера (наприклад, validatesкод у моделі ActiveRecord) та генерувати перевірки на стороні клієнта (наприклад, плагіни jQuery, які потім будуть застосовані до форми.

Очевидно, що вище сказане - це просто місінг, "я мав цю ідею", а не формальна пропозиція. Такі речі, безумовно, складніше, ніж здавалося, коли ідея мене вразила.

Це підштовхує мене до питання: як би ви підходили до проектування методики "один раз, запустіть на сервері та клієнті" для перевірки даних?

Пов'язані підтеми: Чи існують такі інструменти для будь-яких конкретних рамок або технологій клієнт-сервер? Які основні проблеми та проблеми, коли намагаються підтримувати лише один набір перевірок?

За моїм обмеженим досвідом, точки, де необхідна перевірка, є

1. Рівень презентації за допомогою HTML,
2. на рівні після презентації (тобто перевірка Javascript),
3. на рівні комбінації, коли взаємодії між кількома полями повинні бути перевірені разом,
4. на рівні бізнес-логіки та
5. на рівні бази даних.

Кожна з них має різні мови, терміни та тригери. Наприклад, мало сенсу перевірити поле до того, як весь запис буде у стані, якщо ви не хочете перевірити лише один фрагмент. Обмеження на рівні бази даних повинні бути застосовані лише наприкінці перед фіксацією, і їх не можна легко виконати детально.

Пов'язана концепція полягає в тому, що представлення даних змінюється між кожним із рівнів. Простий приклад - веб-браузер представляє фрагмент тексту як, мабуть, CP1290, тоді як база даних представляє його в UTF-8; довжини двох рядків відрізняються, тому примусові обмеження довжини стають незручними.

Одне з питань, що часто обмежує рішення - це поїздка в мережі. Клієнт повинен перевірити дані користувачів, не надсилаючи повідомлення по мережі. Іншими словами, коли користувач натискає кнопку подання, клієнт повинен перевірити дані локально.

Спочатку припустимо, що у нас немає цього обмеження. Ми могли б спілкуватися з мережевою кінцевою точкою, яка добре розбирає питання валідації. Наприклад, коли ви подаєте на нього свою нову запис користувача, замість того, щоб відповідати кодом помилки ванільного HTTP, він може повернути детальну відповідь JSON, яка деталізує проблеми, і клієнт розумно оновить дисплей, щоб відобразити проблеми, з якими він зіткнувся. Кінцева точка відіграє роль шлюзу перевірки.

Це СУХО, але не без недоліків. По-перше, це залежить від мережі, яка оподатковує наш сервер валідаціями, які могли б оброблятись на стороні клієнта. По-друге, дизайн передбачає, що всі операції з CRUD відбуватимуться через наші кінцеві точки, але що робити, коли розробники та процеси обходять наш рівень доступу до даних, прямо проти бази даних ?

Давайте переглянемо наше рішення для подолання цих недоліків. Замість цього давайте зберігати та повідомляти наші перевірки як метадані:

{field: 'username', type: 'required'}
{field: 'username', type: 'unique'} //requires a network roundtrip
{field: 'password', type: 'length', min: 10, max: 50}
{field: 'password', type: 'contains', characters: ['upper', 'special', 'letter', 'number']}

І клієнт, і сервер мали б якийсь механізм (наприклад, двигун) для інтерпретації та застосування цих даних. (Деякі називають це вільною монадою, оскільки вона відокремлює декларативну частину від її інтерпретатора.) У JavaScript ми можемо відобразити кожну частину інформації на робочі функції. Для завантаження ми можемо навчити будь-який шар нашої архітектури, включаючи нашу базу даних, послідовно виконувати перевірки.

Одним із способів було б використання однієї мови / основи як на сервері, так і на стороні клієнта.

Напр

Node.js :: Клієнт / Сервер у JavaScript GET :: Клієнт / Сервер на Java

У цьому випадку більша частина коду "Об'єкт домену" була б загальною, яка включала б перевірку. Framework буде викликати код у міру необхідності. Наприклад, той самий код буде викликатись у браузері перед "надіслати" та на веб-службі на стороні сервера.

EDIT (червень / 2014): З Java 8 тепер легко інтегрувати код перевірки JS і в додатки Java. У Java 8 є новий механізм виконання JS, який є більш постійним (наприклад: він використовує invokeDynamic).

Я просто думав над тією ж проблемою. Я думав використовувати ANTLR для отримання абстрактного синтаксичного дерева як у C #, так і в JavaScript. Звідти ви використовуєте крокуючі дерева, щоб застосувати дії, визначені мовою, до об'єктів, які слід перевірити.

Тоді ви можете зберігати опис необхідної перевірки, де завгодно - можливо, у базі даних.

Ось як я підходив би до проблеми.