#asp.net-mvc #webforms
#asp.net-mvc #веб-формы
Вопрос:
Недавно при разработке веб-приложения среднего и крупного масштаба я решил использовать клиентскую реализацию веб-форм, а не asp.net MVC для уровня пользовательского интерфейса.
Причина в том, что с помощью webforms легко быстро создавать экраны и склеивать веб-приложение (я широко использую radcontrols от Telerik, поскольку у них богатая клиентская модель). Я обнаружил, что чем раньше я получу прототип пользовательского интерфейса перед клиентом, тем быстрее они смогут просмотреть его и превратить в то, что они действительно хотят.
Когда я говорю клиентские веб-формы, я в основном привязываю данные на стороне клиента, а затем использую веб-службы для обработки событий от клиента — веб-службы взаимодействуют с моим бизнес-уровнем и обрабатывают JSON. Преимущество возникает, когда, скажем, одно событие пользовательского интерфейса требует обновления многих элементов управления — тогда я могу вернуться к asp.net цикл страницы и запуск частичной обратной передачи, обернув различные элементы управления в панели обновления.
Насколько я понимаю, у меня может быть свой пирог, и я могу его съесть! Я могу использовать молниеносные веб-сервисы JSON для критически важных областей моего приложения, но я могу вернуться к модели обратной / частичной обратной передачи для сложных областей пользовательского интерфейса. В целом, меньше времени на разработку и производительность там, где это важно.
Итак, наконец, вопрос!
Я не пытаюсь сопротивляться MVC, просто спрашиваю, лучше ли это, чем то, что я делаю выше, и если да, то почему?
Комментарии:
1. Различия между mvc и webforms довольно подробно описаны на боковой панели. Это также довольно субъективно, поскольку разные программисты предпочитают разные шаблоны.
2. очень субъективный вопрос. тонны обсуждений уже без принятия решения с большим количеством поклонников с обеих сторон
3. @jfar — Согласен, субъективная и, возможно, даже немного щекотливая тема на данный момент. Я твердо верю, что web forms находится на выходе и в какой-то момент в будущем устареет. ASP.NET В MVC 3 появился новый движок просмотра (Razor), который является еще одним огромным шагом в сторону от того, что я буду называть «устаревшим» ASP.NET веб-формы.
Ответ №1:
Ваши причины использования веб-форм веские: быстрое прототипирование для получения макета пользовательского интерфейса перед клиентом. Другой причиной может быть огромное количество поставщиков, которые предлагают серверные элементы управления для выгрузки на страницы веб-форм.
Лично я считаю, что MVC имеет некоторую кривую обучения для тех, кто привык использовать конструктор перетаскивания, а не редактировать HTML вручную. Тем не менее, как только вы пройдете через это, я не верю, что вы когда-либо снова будете использовать веб-формы. Появляется множество элементов управления, которые очень хорошо работают с MVC. Расширения MVC от Telerik — это всего лишь один пример, который также имеет открытый исходный код.
Комментарии:
1. не знал, что у них открытый исходный код, это полезно знать — спасибо, взгляну.
2. Я нахожусь в аналогичной ситуации, будучи единственным разработчиком на своей работе. быстрые тупые приложения, которые я могу быстро создавать с помощью веб-форм и элементов управления telerik. я, наконец, сделал решительный шаг в mvc и никогда бы не вернулся, как только понял, что это намного лучше и делает меня намного лучшим разработчиком.
Ответ №2:
В некоторых случаях вы прибегаете к обратной передаче страницы, это означает, что вы фактически поддерживаете две разные модели. Одна на стороне клиента и одна на стороне сервера. В случае обратной публикации вы вносите изменения на стороне сервера, и теперь вам нужно найти способ передать эти изменения на сторону клиента. Я не знаю, как вы это делаете, но это не совсем масштабируемо, потому что каждое изменение должно синхронизироваться как на стороне клиента, так и на стороне сервера. В MVC мы позаботимся об этом, используя модели представления на стороне сервера, которые автоматически обрабатываются фреймворком на стороне клиента. (Кроме того, мы используем библиотеки привязки на стороне клиента, такие как Knockoutjs, которые гораздо проще использовать с MVC, чем webforms)
Во-вторых, вы также не получаете преимуществ маршрутизации в webforms. Итак, ваши маршруты все еще выглядят такими уродливыми Mysite.com/mypage.aspx .
Комментарии:
1. Механизм маршрутизации, который использует MVC, можно использовать с веб-формами. Также я считаю, что IIS7 может делать это изначально, поэтому вы не обязательно застряли с неприятными aspx-URL.
2. клиентские веб-службы и код обратной передачи (в исходном коде) вызывают одни и те же методы API уровня сервиса. Клиент поддерживает целостность пользовательского интерфейса до следующей обратной отправки или перезагрузки, когда сервер все повторно синхронизирует. Я слышу хорошие вещи о knockoutjs — проведу расследование. Спасибо.
3. @Yuck: Вы можете делать в webforms все, что вы можете делать в MVC, но, в конце концов, вы пытаетесь пойти против того, для чего на самом деле была создана технология.
4. @iandyman: вы имеете в виду, что в случае частичной обратной передачи вы не обновляете данные на стороне клиента? и ждать этого до следующего полного обновления страницы? не похоже на хорошую стратегию.
5. частичные пост-бэк-версии обновляют клиент для элементов управления в разделе «Панели обновления». Стратегия работает, хотя я понимаю вашу точку зрения о том, что она противоречит тому, для чего была создана технология.
Ответ №3:
У меня есть приложение для недвижимости здесь: www.homevana.com . Это приложение для веб-форм, но я уверен, что вы этого не знаете. Для требований этого проекта идеальным вариантом было клиентское приложение, которое все еще использовало веб-формы, когда требовалось заполнить большие сложные формы для сбора данных о доме на продажу. Итак, большинство .aspx-страниц в приложении Homevana не содержат кода, но при наличии форм со сложной проверкой я использовал .aspx-страницы с серверными элементами управления и набор проверки Питера Блюма:http://www.peterblum.com/Home.aspx (конечно, вся сложная проверка на стороне клиента), чтобы быстро выполнить этот аспект работы.
Пакет FriendlyUrl, который вы можете установить через nuget: http://www.hanselman.com/blog/IntroducingASPNETFriendlyUrlsCleanerURLsEasierRoutingAndMobileViewsForASPNETWebForms.aspx легко избавляется от этого «уродливого» расширения .aspx, хотя вы также можете сделать это с помощью одного правила маршрутизации URL-адресов регулярных выражений IIS7.
Все дело в правильном инструменте для работы. MVC потрясающий, и у меня есть много других проектов, где я использую MVC, но это не всегда лучший инструмент для требований проекта.