API веб-фреймворка

Question

Я не веб-разработчик, и я не очень разбираюсь в фреймворках веб-приложений.

Однако недавно я попал в Wt .Это веб-фреймворк, написанный на C ++ (вот почему я в него попал), но больше всего меня поразила идея, на которой он основан.

Его API отличается от любого веб-фреймворка, о котором я когда-либо слышал (CppCMS,Yii, Django, Pylons, Zope, Drupals, Java Servlets, Struts ...): новый объект Application создается для любого пользовательского сеанса и остается в живых до истечения сеанса (только в этот момент объект Application уничтожается).Этот объект приложения работает как окно рабочего стола: вы помещаете в него виджеты (виджеты, такие как формы, ссылки, метки ...);когда пользователь нажимает на ссылку (когда HTTP-сервер получает новый запрос GET / POST), вызывается функция для объекта, тесно связанного с пользовательским сеансом (приятным способом Signal / Slot), который может удалить / добавить / изменитьвиджеты, таким образом изменяя страницу, которую увидит пользователь.

Как я уже сказал, я не очень разбираюсь в веб-фреймворках, я разрабатываю почти только настольные приложения;может быть, по этой причине я думаю, что эта парадигма позади Wt великолепна.

Я хотел бы знать, каковы плюсы и минусы этого каркасного API по сравнению с другими, и еслиСуществуют и другие структуры (также на других языках), основанные на тех же принципах.

Answer 1

Wt является отличной основой для предполагаемого диапазона применения .

Wt отлично подходит для:

• веб-приложений, тесно связанных с сеансом, т.е.
  • сделано для доступа только тем пользователям, которые вошли в систему (кроме целевой страницы)
  • отображать много пользовательского контента (не для вики)
  • сильно зависит от состояния
• веб-приложений, которые должны иметь множество элементов управления / кнопок и пользовательский ввод.

Например, я планирую написать браузерную MMORPG. Страницы будут иметь состояние, привязанное к пользователю, и будет много кнопок. Wt идеально подходит для этого . Раньше я был разработчиком Ruby on Rails, и переключение на Wt для такого рода приложений было отличным моментом. Проектирование форм с использованием традиционных сред, которые пытаются использовать чистый REST, становится все более громоздким.

Wt также идеально подходит для интерфейса управления в каком-либо процессе. Например, интерфейс, позволяющий вашим клиентам настраивать кампанию AdWord и т. Д.

Конечно, использование Wt не идеально для управления и разделения, но оно позволяет чрезвычайно быстро разрабатывать, когда вам нужны только "классические" функции (кнопки, редакторы и т. Д.)

Так что, как правило, если вы пытаетесь разместить настольное приложение в Интернете (что является отличной идеей, устраняя необходимость развертывания и обновления на компьютерах ваших клиентов), Wt является хорошим кандидатом.

Кроме того, если вы взаимодействуете с существующей кодовой базой C ++, у Wt есть преимущество.

Answer 2

Я думаю, что это вообще плохая идея.

Веб-приложение сильно отличается от графического интерфейса, и есть много причин:

99% Интернета - это содержание, а не итерация.

Вы идете в Интернет, чтобы получать или делиться контентом, а не для взаимодействия в реальном времени. как рисование картины, работа с таблицей или что-то еще. Web - это скорее контент-ориентированное, а не управляемое событиями интерактивное приложение.

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

Программирование сервера и клиента сильно отличается

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

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

Потому что должно быть очень четкое разделение между серверной и клиентской работой. поскольку некоторые требуют ответа в реальном времени, а некоторые нет.

При попытке решить все это за одно ожидание проблем. Обратите внимание, есть клиент-сервер решения для графического интерфейса (см. X-Server в качестве примера), но в отличие от веб-сайтов, они предназначены для этого и скорее работать больше как IPC, а не как клиент-серверные решения.

В большинстве случаев в Интернете нет состояний.

Или, если быть более точным, состояние обычно хранит довольно небольшой объем данных.

Создание объекта мгновенного сеанса - хорошая идея, пока вам не нужно ... Масштабировать состояние сохранения в долгосрочной перспективе, тогда эта модель, конечно, станет не очень хорошей это не «вынужденная» модель Wt, но это общая концепция, которая соответствует определенной концепции а некоторые нет.

Итог

Если вы хотите создать хороший графический интерфейс, например, веб-приложение. Начните изучать JavaScript и используйте хорошие JavaScript-фреймворки с графическим интерфейсом, которые хорошо вписываются в графический интерфейс, даже управляемый. Затем объедините их с некоторым API на стороне сервера, используя модель взаимодействия RPC, такую ​​как Json-RPC, XML-RPC и другие. Инструменты AJAX.

Это способ сделать все правильно для высокоинтерактивных приложений.

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

Все в одном решении? Просто не работает ...

Раскрытие информации: Я разработчик CppCMS , и я думаю, что Wt просто идет не так, как надо.

Answer 3

ASP.NET аналогичен; он имеет ту же цель, чтобы сделать веб-разработку похожей на разработку настольных приложений.