Управление приложениями .NET / Server Side строго через клиентский UX.

Question

Я разрабатывал в стеке .NET последние пять лет, и с последней версией MVC3 и .NET 4.0 я чувствую, что направление, в котором, как я думал, все движется, получило дальнейшее подтверждение.

С инновационными шагами, которые клиентское сообщество делает за такой короткий период времени, кажется, что лучшие в своем классе приложения имеют UX, контролируемый большинством событий клиента. Например, facebook.com, stackoverflow.com, google, www.ponched.com :) и т. Д. Когда я говорю о клиентских событиях, я не говорю о серверном элементе управления, обернутом в UpdatePanel для маскировки обратной передачи. Я говорю о выполнении всех событий и переходов экрана на клиенте и использовании полных обратных передач только тогда, когда это действительно необходимо. Нельзя сказать, что такие вещи, как .NET, не являются необходимыми инструментами, помогающими контролировать безопасность, начальную загрузку страницы, маршрутизацию, средний уровень и т. Д.

Я понимаю, что при работе над простым приложением или в условиях жестких временных ограничений использование элементов управления и функциональных возможностей, предоставляемых по умолчанию в .NET (или других платформах веб-разработки), нецелесообразно, если проект требует этого, но кажется, что разработчики которые могут отличаться друг от друга - это те, которые вы можете получить в траншеях Javascript / jQuery и предоставить цельные приложения, которые имеют ограниченное участие со стороны (веб) сервера. Как разработчики, мы не можем думать, что наши пользователи становятся все более изощренными из-за громких веб-приложений, которые они используют в Reg, но я склонен думать, что это так.

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

Answer 1

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

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

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

Answer 2

Дело в том, что разработчики, которые ставят себя отдельно, определенно нацелены.Разработчики, которые понимают базовые технологии и могут разрабатывать индивидуальные решения для своих клиентов, действительно отделены от разработчиков, которые могут перетаскивать инструменты фреймворка и подключать что-то, что работает достаточно хорошо.

Сосредоточив внимание на веб-разработке в этом обсуждении,жизненно важно, чтобы разработчики понимали ключевые технологии в игре.Я не могу сосчитать, сколько раз я сталкивался с «веб-разработчиками» (в первую очередь в стеке Microsoft, поскольку именно там я в основном работаю), которые явно отказываются изучать JavaScript / HTML / CSS просто потому, что считают, что инструменты для них доступны.в Visual Studio отлично справляется со своей задачей.

Во многих случаях это так, но не во всех случаях.И способность решать случаи, когда это не так, ставит разработчика выше остальных.Такая простая вещь, как предоставление небольшого API-интерфейса RESTful JSON и использование вызовов AJAX для извлечения только необходимых данных вместо размещения всей страницы и повторной обработки всего ответа, очень много значит для общего пользовательского опыта.Оба выполняют свою работу, но одно значительно более впечатляет пользователей, чем другое.

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

Answer 3

Вы правы, говоря, что в современной веб-разработке используются такие технологии, как jQuery (или аналогичные библиотеки) и JavaScript в целом.

Полные перезагрузки страницы - старомодный подход, и подход Ajax - путь, только не думайте, что веб-сервер используется меньше или задействован меньше, чем прежде, он все еще отвечает на вызовы ajax, просто делает это асинхронно:)

MVC на самом деле не поддерживает обратную запись, потому что нет веб-форм и не существует той же модели жизненного цикла страницы.