Чистый интерфейсный 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, чем он / она.

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

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

Я предложу свою очень субъективную ценность 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.

То, что я сделал, было:

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

По существу, интерфейс JS связывается с REST API для операций CRUD и заполняет HTML возвращенными данными или созданными данными, либо удаляет удаленные данные или обновляет измененные данные.

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

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

Плюсы:

• Возможность вносить изменения в HTML из-за того, что он не генерируется JS;
• Снижение потребления полосы пропускания за счет использования ajax и JSON;
• Более низкое потребление серверной обработки, поскольку HTML заполняется на стороне клиента;
• Улучшенный пользовательский интерфейс благодаря использованию JS для изменения экрана, позволяющий использовать эффекты и увеличивающий скорость рендеринга.
• Лучшее использование протокола HTTP с помощью REST.

Минусы:

• 2 заявки на обслуживание;
• Зависит от клиентской обработки, которая может быть плохой из-за плохого оборудования.

Надеюсь это поможет.

С Уважением,

Что касается validationаспекта в Web Api - можно выполнить «проверку модели» и ответить HTTP-запросом 400 неверных запросов.

См. Https://stackoverflow.com/questions/11686690/handle-modelstate-validation-in-asp-net-web-api/25050285#25050285