Переміщення всієї логіки інтерфейсу на сторону клієнта?

9

Наша команда спочатку складалася з переважно серверних розробників з мінімальними знаннями в JavaScript. У ASP.NET ми писали багато логіки інтерфейсу в кодовому режимі або останнім часом через контролери в MVC.

Нещодавно до нашої команди приєдналися 2 розробники високого рівня клієнтів. Вони можуть робити в HTMl / CSS / Javascript майже все, що ми могли раніше робити з кодом на стороні сервера та веб-контролями на стороні сервера:

Показати / приховати елементи керування
Зробіть перевірку
Керуйте освіжаючим AJAX

Тож я почав думати, що, можливо, було б ефективніше просто створити API високого рівня навколо нашої логіки бізнесу, на кшталт API Amazon Fulfillment: http://docs.amazonwebservices.com/fws/latest/APIReference/ , щоб клієнт сторонні розробники повністю переймуть користувальницький інтерфейс, в той час як розробники сервера зосереджуються лише на бізнес-логіці.

Отже, для системи замовлення у вас буде API високого рівня, наприклад:

OrderService.asmx

CreateOrderResponse CreateOrder(CreateOrderRequest)
AddOrderItem
AddPayment
-
SubmitPayment
-
GetOrderByID
FindOrdersByCriteria
...

Був би доступ JSON / REST до API, тому його було б легко споживати з інтерфейсу на стороні клієнта. Ми могли використовувати цей API як для внутрішньої розробки інтерфейсу, так і для третіх сторін для створення власних додатків.

З розвитком Javascript та наявністю хороших розробників на стороні клієнта, чи справді час позбутися кодування / контролерів та просто зосередитись на розробці API високого рівня (ала Amazon), який можуть споживати розробники на стороні клієнта?

— Mag20
джерело

6

Перевірка на стороні клієнта для завантаження серверної сторони та підвищення чутливості програми добре, але завжди виконуйте перевірку на стороні сервера. Можна вимкнути JavaScript, і при прямому використанні API REST жоден JavaScript ніколи не буде потрібен.

— Htbaa
джерело

Так, перевірка також буде частиною Домену / API. Клієнтська сторона отримає те, що потрібно перевірити з API, або ми задокументуємо те, що потрібно, тощо ... для кожного методу. Якщо в поданні від клієнта все ще є помилки перевірки - ми б викинули винятки.

— Mag20,

4

Слід пам’ятати, що складні інтерфейси можуть потребувати додаткового рівня «UI-допомога» для підтримки таких речей, як ієрархії, стосунки майстер / деталі та інші концепції інтерфейсу, які насправді не існують на рівні бізнесу. Часто неможливо реалізувати деякі з цих можливостей без здійснення декількох поїздок до бізнес-рівня, що знижує продуктивність. Принаймні, я вважаю за краще, щоб рівень «допомога у користувальницькому інтерфейсі» надав безпосередньому доступу до бази даних.

— TMN
джерело