Используя ExtJS с ASP.NET, Webforms или MVC? - PullRequest
4 голосов
/ 12 ноября 2009

Для сценария, в котором вообще используется 0 элементов управления ASP.NET, а не 100% интерфейс extJS, какие будут преимущества использования ASP.NET MVC или ASP.NET WebForms? А недостатки? Есть ли ОБЫЧНЫЙ способ сделать это правильно?

Я бы хотел получить отзыв о вашем опыте.

Спасибо!

Ответы [ 5 ]

10 голосов
/ 12 ноября 2009

WebForms + любой чисто клиентский фреймворк не даст вам ничего, кроме бесконечных головных болей, если вы вообще сможете заставить его работать. Некоторые из проблем, с которыми я сталкивался в прошлом (это было давно):

  • WebForms ограничивает вас одним <form> тегом на странице. Хотя это не обязательно препятствует использованию Ext или чего-то подобного, во многих случаях оно строго (и произвольно) ограничивает
  • WebForms построен на основе обратных передач и viewstate. Предполагая, что вы не используете эти функции (поскольку у вас нет серверных элементов управления), вы будете бороться с тем, как WebForms хочет работать. Вы можете сделать это, но все становится очень быстро.
  • WebForms имеет полный жизненный цикл страницы и инфраструктуру событий на стороне сервера. Опять же, поскольку вы не будете использовать ничего из этого, какой смысл выбирать веб-формы?
  • Вы застряли с неприятными URL, если не хотите по-настоящему бороться с IIS.

ASP.Net MVC - намного лучшая альтернатива, если вы все еще хотите воспользоваться тем, что .NET может предложить на стороне сервера без страданий, связанных с WebForms. Есть также несколько различных поставщиков Ext.Direct для MVC, доступных на форумах Ext, если вы ищете. Удачи вам найти что-нибудь, что поможет вам интегрировать Ext с WebForms (ничего нет).

РЕДАКТИРОВАТЬ : Я использовал эту реализацию стека Ext.Direct для ASP.NET MVC некоторое время с отличными результатами.

6 голосов
/ 12 ноября 2009

Рассмотрите возможность создания внешнего интерфейса Ext JS отдельно от сервера.

Это разделение вынуждает вас создавать чистое приложение javascript и держит вас вдали от проблем, возникающих у "помощников" в различных структурах.

Это сокращает время, в течение которого вы будете «переключать передачи» между серверными языками и javascript. По моему опыту, особенно для разработчиков, плохо знакомых с Ext JS, самым большим препятствием является отделение логики интерфейса от логики на стороне сервера.

И это будет очень быстро! Общайтесь с сервером, используя чистый HTTP и JSON, и создайте приложение Ext JS, как и было задумано!

1 голос
/ 01 июня 2010

ASP.Net MVC было бы лучше для интеграции с ExtJ. Если вам нужно использовать веб-формы, я бы посоветовал взглянуть на http://www.coolite.com/. Это оболочка ASP.Net поверх ExtJ и, вероятно, облегчит жизнь.

1 голос
/ 12 ноября 2009

Для этого я бы предпочел использовать стиль MVC ASP. В основном это потому, что ASP.net имеет тенденцию добавлять случайный мусор, который вам не нужен. То, что вы хотите, - это самая чистая вещь для передачи данных в ExtJS. Если вам вообще не нужно взаимодействие с сервером, скажем, вы отправляете введенные данные обратно в Azure или S3, тогда вам вообще не нужен ASP, вы можете отправлять статический HTML.

0 голосов
/ 12 ноября 2009

Другая перспектива: я создаю веб-клиент в extjs для удаленного взаимодействия .NET-сервера в домене. Я думаю, что я мог бы просто выдвинуть «сырые» данные в ext, так как серверное приложение обрабатывает всю логику, но поскольку мое удаленное взаимодействие не «веб-ориентировано», я использую набор пользовательских обработчиков http (.ashx) для разбора параметров и установить MIME-типы, обработку сеанса и все, что связано с веб-сервером. Поскольку эта архитектура работает очень хорошо с несколькими сценариями .ashx, я не чувствую необходимости использовать более изящные настройки, такие как ASP.NET MVC (я даже не думаю, что это подойдет), но я также не использую WebForms.

...