Чистий JavaScript на передньому кінці з веб-API проти MVC-переглядів з ajax

Це було більше обговоренням того, що думають народи сьогодні про те, як розділити веб-додаток.

Я звик створювати додаток MVC з усіма його переглядами та контролерами. Як правило, я створюю повний вигляд і передаю його назад до браузера за запитом на повну сторінку, якщо тільки немає конкретних областей, які я не хотів би безпосередньо заселяти, і тоді я б використовував події завантаження сторінки DOM, щоб викликати сервер для завантаження інших областей за допомогою AJAX.

Крім того, коли мова зайшла про часткове оновлення сторінки, я б назвав метод дії MVC, який би повернув фрагмент HTML, який я міг би використати для заповнення частин сторінки. Це було б для областей, які я не хотів сповільнювати початкове завантаження сторінки, або областей, які краще підходили до дзвінків AJAX. Один із прикладів може бути підказками таблиці. Якщо ви хочете перейти на наступну сторінку, я вважаю за краще, якщо дзвінок AJAX отримав цю інформацію, а не використовувати повне оновлення сторінки. Але виклик AJAX все одно поверне фрагмент HTML.

Моє запитання. Чи мої думки щодо цієї архаїки, тому що я походить з .net фону, а не з чистого фону переднього кінця?

Розумний розробник переднього кінця, з яким я працюю, вважає за краще робити більш-менш нічого в представленнях MVC, і вважає за краще робити все на передній частині. Праворуч до веб-дзвінків API, що заповнюють сторінку. Так що замість виклику методу дій MVC, який повертає HTML, він вважає за краще повертати стандартний об'єкт і використовувати JavaScript для створення всіх елементів сторінки.

Спосіб розробника на передньому кінці означає, що будь-які переваги, які я зазвичай отримую при валідації моделі MVC, включаючи перевірку на стороні клієнта, не втрачаються. Це також означає, що будь-які переваги, які я отримую зі створення переглядів, із сильно набраними HTML-шаблонами тощо, не будуть втрачені.

Я вважаю, що це означатиме, що мені потрібно написати однакову перевірку для перевірки переднього та заднього кінців. У JavaScript також потрібно мати безліч методів для створення всіх різних частин DOM. Наприклад, додаючи новий рядок до таблиці, я зазвичай використовую частковий вигляд MVC для створення рядка, а потім повертаю це як частину виклику AJAX, який потім вводиться в таблицю. Використовуючи чистий передній спосіб, javascript взяв би об'єкт (для, скажімо, продукту) для рядка з виклику api, а потім створить рядок з цього об'єкта. Створення кожної окремої частини рядка таблиці.

Веб-сайт, про який йдеться, матиме безліч різних областей: від адміністрації, форм, пошуку продуктів тощо. Веб-сайт, який, на мою думку, не потребує архітектури у формі додатків на одній сторінці.

Які думки кожного з цього приводу?

Мені цікаво почути з передніх дев і задніх дев.

Я також дещо скептично налаштований, що кожен новий веб-додаток повинен бути SPA, але одне, на що я продаюсь на 100% як генераліст, основна частина його досвіду на стороні клієнта - це архітектура, орієнтована на сервіс, яка надає перевагу Дані, а не HTML для клієнта, - це шлях для того, чи завантажуєте ви попередньо вбудовані сторінки / перегляди з сервера і чимало динамічних речей із даними після завантаження сторінки або будуєте майже все на 100% за допомогою JavaScript.

Причини, які є кращими для розробника на стороні клієнта, майже такі ж, як і причини, чому ніхто не хоче HTML в базі даних. Що повинен робити розробник на стороні клієнта, коли вони хочуть вдатися до таблиці, наприклад, коли їм передали HTML? Вартість продуктивності обробки всього, що є на клієнті, є тривіальною порівняно з поданням іншого серверного запиту зробити це для вас. Також побудова HTML дуже добре висвітлена в JS-land. Сортування даних та створення нових рядків таблиць HTML - це досить тривіальна робота для досвідченого розробника на стороні клієнта.

І від чого корисна архітектура зворотного кінця для переднього кінця для іншого пристрою, який, можливо, повинен зробити щось екзотичне, як реалізувати віджети, що мають 100% полотно або зовсім іншу HTML-структуру? Чому розробнику на стороні клієнта доводиться завантажувати візуальну студію або стукати у двері диванів заднього кінця, щоб зробити суворо презентаційний виправлення?

Що стосується ваших занепокоєнь щодо втрати сильно набраної валідації шаблону, повірте мені, коли я скажу, що якщо ви маєте справу з компетентним розробником на стороні клієнта, ви не знайдете .NET Framework або візуального інструментального студії, який би більш вугільним. алмаз-пил-подрібнювач анальний щодо добре сформованого, дійсного HTML, ніж s / he.

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

Я думаю, що також простіше міркувати про задню архітектуру, коли ви повністю виділили її з усіх матеріалів презентації. Ви більше не захоплюєте дані, щоб перемістити їх у якийсь HTML. Ви збираєте її разом, щоб створити незалежну від реалізації структуру даних, яка стосується себе більше загального використання, ніж того, що буде зроблено з нею з іншого боку. IMO, це, як правило, призводить до більшої послідовності в обробці справ, оскільки дані тепер є кінцевою метою, а не другим та останнім кроком процесу, і існує менше можливостей для непов'язаних проблем, щоб перевести їх провід.

Я запропоную свою високо суб’єктивну вартість 2 копійки (для чого вона варта;)). На це немає правильної чи неправильної відповіді, а крім ваших питань, є багато реальних міркувань, наприклад:

• Чи маєте ви відповідний досвід роботи в будинку? побудова додатка, керованого клієнтом, дуже відрізняється від сервера, керованого переважно сервером із зовсім іншим набором навичок.
• Скільки часу ви хочете, щоб це зайняло і які браузери вам потрібно підтримувати? - чим більше ви робите на клієнті, тим більше проблем із браузером ви будете стикатися; IE8 болісний, а продуктивність JavaScript є досить низькою, але є багато підприємств, що працюють із налаштуваннями XP / IE.
• На яких пристроях ваші користувачі переглядатимуть сайт? Розбір і запуск JavaScript може бути швидким для останньої версії Chrome - але це не на старих мобільних пристроях, особливо це не велика кількість JavaScript з великою кількістю бізнес-логіки.
• Наскільки важливим є початкове навантаження? Шаблони сервера швидше, ніж клієнтські шаблони

Цей список аж ніяк не є вичерпним і здається, що забій на стороні клієнта, що не є моїм наміром, я робив сайти з великим акцентом на передній частині.

Для мене це дійсно зводиться до досвіду користувача та повторної використання API. Щоб вирішити кожне з них.

Якщо ви збираєтеся робити додаток або пропонувати API, у використанні проекту .Net API багато сенсу, це формує крос-платформу логіки, перевірки та реалізації. У цьому випадку повний підхід до клієнта може бути сприятливим, API може підтримуватися окремо і просто надає інтерфейс вашій програмі. Ви можете зручно вносити зміни до логіки та рефактора, і просто потрібно підтримувати інтерфейс однаковим. Ви можете легко писати різні програми для різних носіїв інформації, використовуючи один і той же фоновий код.

Найсильніший аргумент для чистого переднього рішення (на мою думку) - це досвід користувача.

Чи (враховуючи всі недоліки) чисте програмне забезпечення для браузера JavaScript суттєво покращить зручність використання та користувацький досвід на традиційному веб-сайті?

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

Я вважаю, що це досить прагматично, це не є ані питанням, ані питанням; JavaScript, очевидно, гратиме разом із технологіями сервера, і вам не доведеться вибирати те чи інше - кожен сайт не є веб-додатком на одній сторінці - але ніщо не зупиняє вас використовувати Knockout, магістраль та подібне на окремих сторінках для вдосконалити речі там, де це вважається необхідним.

Я маю відносини любові-ненависті до важких застосувань.

З одного боку, я люблю писати JavaScript і люблю браузер як середовище виконання.

З іншого боку, обидва відчувають себе гоночним автомобілем Формули-1 з отворами в двигуні. Це дійсно зводиться до цього: Чи можете ви запобігти дублюванню логіки бізнесу між C # та JavaScript? Якщо так, то використовуйте будь-який метод для формування подання, яке ви вважаєте гідним. Якщо ви дублюєте бізнес-логіку двома мовами, у вас може бути розробник, що просто хоче написати JavaScript, і не дуже добре бачить велику картину.

Щодо технічних відмінностей:

Надання часткової та доставка її клієнту:

• Легкий і швидкий в реалізації
• Запобігає дублюванню логіки бізнесу на передній частині
• Це може призвести до набагато більшого завантаження HTTP для браузера. Непогана річ на робочому столі з високою пропускною здатністю. Дуже погано на слабкому мобільному телефоні, поки ви сидите в годину пік, коли швидкісний потяг із швидкістю 60 км / год і 1000 інших мобільних телефонів одночасно відключаються від однієї стільникової вежі та намагаються знову підключитися до наступної стільникової вежі.

Подання JSON та надання шаблону на стороні клієнта:

• Це може призвести до меншої корисної навантаження HTTP, ніж HTML, що може зробити додаток більш чутливим через ненадійні або повільні мережеві з'єднання.
• Багато мов шаблонів JavaScript повністю представлені, це означає, що нам не потрібен бекенд, щоб створити HTML

Іноді я думаю, що новіші рамки JavaScript викидають дитину разом з водою у ванну --- чоловік, я сподіваюся, що я не став бурхливим програмістом куркулі ...

У своєму останньому додатку я поєднав REST api та JavaScript front-end.

Що я зробив:

• Я створив API REST для операцій CRUD.
• Я створив додаток Javascript, який завантажує заздалегідь задані шаблони HTML і заповнює дані, повернені з API REST.

В основному JS-інтерфейс спілкується з REST API для операцій CRUD та заповнює HTML-код поверненими даними або створеними даними, або видаляє видалені дані або оновлює змінені дані.

Таким чином, у нас є чистий HTML, ми обробляємо роботу з клієнтом, у нас є менша кількість пропускної здатності, не потрібно завантажувати весь HTML і можемо користуватися справді Web 2.0 для користувачів.

Я не роблю перевірки бізнесу на передньому кінці для безпеки та дублювання коду, оскільки кожен може змінити дані перед тим, як надсилати їх на сервер, і нам доведеться ще раз перевірити дані на сервері. Тому це було б легко зламано. Усі перевірки проводяться на бек-енді. Перевірки на стороні клієнта проводяться лише для типів введення.

Плюси:

• Засіб для внесення змін у HTML через те, що він не генерується JS;
• Менше споживання пропускної здатності за допомогою ajax та JSON;
• Менше споживання серверної обробки, оскільки HTML заповнюється на стороні клієнта;
• Покращений досвід роботи користувачів за допомогою використання JS для зміни екрана, що дозволяє використовувати ефекти та збільшувати швидкість візуалізації.
• Краще використовувати протокол HTTP, використовуючи REST.

Мінуси:

• 2 додатки, що підлягають підтримці;
• Залежить від обробки клієнта, що може бути погано через неякісне обладнання.

Сподіваюсь, це допомагає.

З повагою,

Що стосується validationаспекту в Web Api - можна зробити "перевірку моделі" та відповісти на відповідь на 400 неправильних запитів http.

Перегляньте /programming/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285