Периодически возникает необходимость создавать веб интерфейс для пользователей приложений.
Приложения выполняются на сервере, результаты своей работы сохраняют в базе данных.
Пользователь должен иметь возможность создать задание, редактировать его, запускать, смотреть статус, выполнять другие аднминистративные функции. По окончании задачи доступны всякие отчеты.
Традиционно интерфейс пишется с использованием парадигм, навязанных asp.net.
То есть интерфейс практически не хранит состояние, максимум немного данных в сессии.
При каждом запросе мы смотрим кто пришел, начинаем думать — что ему нужно — тянуть данные из базы, формируем ответ и все забываем.
Это нормальная практика для приложений, у которых много клиентов.
В моем случае одновременно клиентов единицы, максимум десятки. Больше их не станет, поскольку каждая задача требует много ресурсов сервера, и веб интерфейс не основной фактор нагрузки.
Есть желание программировать интерфейс, практически как экземпляр десктопного приложения, не сбрасывая граф обьектов пользователя после каждого запроса. То есть залогинился пользователь — получил на сервере инстанс приложения интерфейса — и с ним работает. Инстанс не умирает между запросами.
Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?

Здравствуйте, Chrome, Вы писали:

C>Периодически возникает необходимость создавать веб интерфейс для пользователей приложений.
C>Приложения выполняются на сервере, результаты своей работы сохраняют в базе данных.
C>Пользователь должен иметь возможность создать задание, редактировать его, запускать, смотреть статус, выполнять другие аднминистративные функции. По окончании задачи доступны всякие отчеты.
C>Традиционно интерфейс пишется с использованием парадигм, навязанных asp.net.
C>То есть интерфейс практически не хранит состояние, максимум немного данных в сессии.
C>При каждом запросе мы смотрим кто пришел, начинаем думать — что ему нужно — тянуть данные из базы, формируем ответ и все забываем.
C>Это нормальная практика для приложений, у которых много клиентов.
C>В моем случае одновременно клиентов единицы, максимум десятки. Больше их не станет, поскольку каждая задача требует много ресурсов сервера, и веб интерфейс не основной фактор нагрузки.
C>Есть желание программировать интерфейс, практически как экземпляр десктопного приложения, не сбрасывая граф обьектов пользователя после каждого запроса. То есть залогинился пользователь — получил на сервере инстанс приложения интерфейса — и с ним работает. Инстанс не умирает между запросами.
C>Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?

Выделенное — основной аргумент? Если да, то могу посоветовать изучать веб-программирование.

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

Здравствуйте, gandjustas, Вы писали:

C>>Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?

G>Выделенное — основной аргумент? Если да, то могу посоветовать изучать веб-программирование.

G>Вообще говоря приложение грамотно написанное с расчетом на высокую нагрузку при малой нагрузке летает как сверхзвуковой истребитель. А если "памяти хватит, она дешевая", то можно увеличить размер кеша и получить еще больший прирост.

Зачем получать еще больший прирост производительности, если она не является узким местом?
Хочется выяснить, может в рамках описанных условий возможно применять более простые, дешевые, понятные модели программирования.
Программирование десктопных систем мне кажется очевидно более простым, чем веб программирование нагруженных веб серверов.
Из пушки по воробьям стрелять дорого.

Chrome пишет:
>
> Есть желание программировать интерфейс, практически как экземпляр
> десктопного приложения, не сбрасывая граф обьектов пользователя после
> каждого запроса. То есть залогинился пользователь — получил на сервере
> инстанс приложения интерфейса — и с ним работает. Инстанс не умирает
> между запросами.
> Программировать в таком стиле легче. Памяти хватит, она дешевая. Что
> думаете? Есть ли подводные камни?

Нормальный подход, главное — не забыть вовремя "разлогинить"
пользователя, просто закрывшего браузер (обычно решается с помощью
heartbeat). Кстати, если памяти жалко, между запросами можно
сериализовать объекты на диск (по-моему так делает Spring WebFlow).

Из подводных камней — актуальность объектов, закешированных в сессии
пользователя, их размер. Плюс если пользователи могут модифицировать
один и тот же объект — concurrent modification (эта проблема будет и при
применении традиционного подхода, просто здесь она более явно вылезает).

Ну и про transaction management надо заранее подумать.

--
WBR,
Serge.

Здравствуйте, Chrome, Вы писали:

C>Хочется выяснить, может в рамках описанных условий возможно применять более простые, дешевые, понятные модели программирования.
Asp.Net-ый WebForms — и есть эмулятор десктопа на web. Включаешь ViewState по максимуму и ни о чем не думаешь.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, Chrome, Вы писали:

C>>Хочется выяснить, может в рамках описанных условий возможно применять более простые, дешевые, понятные модели программирования.
IB>Asp.Net-ый WebForms — и есть эмулятор десктопа на web. Включаешь ViewState по максимуму и ни о чем не думаешь.

И получаешь мегабайтные страницы, которые даже по 100-мегабитной сетке с заметным лагом передаются.
Кроме того активное использование постбеков (иначе вьюстейт не нужен) разрушает навигацию, это усложняет работу пользователя.

Здравствуйте, IB, Вы писали:

IB>Asp.Net-ый WebForms — и есть эмулятор десктопа на web. Включаешь ViewState по максимуму и ни о чем не думаешь.

Это он в розовых мечтах майкрософт такой
попытка же применить WebForms как desktop GUI, ни о чем не думая — на практике спотыкается на первом же динамически созданном контроле.

Другие недостатки — необходимость сериализовать и десиарилизовать обьекты приложения — это как минимум муторная работа со всякими иерархиями — а бывают еще и открытые ресурсы...

десктопное прилоение может использовать потоки, в которых исполняется логика задачи и взаимодействовать из этих потоков с интрерфейсом (MessageBox.Show)
В WebForms приходится извращаться, ручками превращая поток в конечный автомат и сериализовать состояние этого автомата в веб форме — типа от пользователя пришел сигнал А, на прошлом шаге мы находились в состоянии Б — значит переходим в состояние С и выполняем соответствующие шаги...

Здравствуйте, gandjustas, Вы писали:

G>И получаешь мегабайтные страницы, которые даже по 100-мегабитной сетке с заметным лагом передаются.
Ну и что? Автора же масштбируемость не волнует.

G>Кроме того активное использование постбеков (иначе вьюстейт не нужен) разрушает навигацию, это усложняет работу пользователя.
Автор хотел как в десктопе, в десктопе над навигацией не парятся.

Здравствуйте, Chrome, Вы писали:

C>Это он в розовых мечтах майкрософт такой
Это он таким задумывался.

C>попытка же применить WebForms как desktop GUI, ни о чем не думая — на практике спотыкается на первом же динамически созданном контроле.
Создавай статически.

C>десктопное прилоение может использовать потоки, в которых исполняется логика задачи и взаимодействовать из этих потоков с интрерфейсом (MessageBox.Show)
C>В WebForms приходится извращаться, ручками превращая поток в конечный автомат и сериализовать состояние этого автомата в веб форме — типа от пользователя пришел сигнал А, на прошлом шаге мы находились в состоянии Б — значит переходим в состояние С и выполняем соответствующие шаги...
Ну, мужик — это веб. Ты думал, в сказку попал? Привыкай. WebForms дает максимум похожести на обычный десктоп.

Правда есть другая альтернатива — Silverlight.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, gandjustas, Вы писали:

G>>И получаешь мегабайтные страницы, которые даже по 100-мегабитной сетке с заметным лагом передаются.
IB>Ну и что? Автора же масштбируемость не волнует.
Тут не в масштабируемости дело, а в том, что придется бороться с такими "простыми" спосбами, чтобы приложение с приемлимой скоростью работало.

G>>Кроме того активное использование постбеков (иначе вьюстейт не нужен) разрушает навигацию, это усложняет работу пользователя.
IB>Автор хотел как в десктопе, в десктопе над навигацией не парятся.
Только кнопку "назад" в браузере не запретишь.

Здравствуйте, Chrome, Вы писали:

C>Периодически возникает необходимость создавать веб интерфейс для пользователей приложений.

C>Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?

А требование именно веб интерфейса чем продиктовано? Заставить веб приложение работать также как десктопное значительно труднее и сложнее в поддержке чем написать такое же, но в нормальном веб стиле. Реально выхода у вас два: вместо "сделать как в винформз" "сделать в winforms" или осознать преимущества stateless и набить руку в программировании веб интерфейсов. Если решите пойти вторым путем — откажитесь от webforms, они намеренно уводят в сторону statefull и постбеков. Попробуйте ASP.Net MVC, там stateless вполне органичен и удобен.

Еще рассмотрите альтернативные варианты типа silverlight'а.

Здравствуйте, IB, Вы писали:

IB>Ну, мужик — это веб. Ты думал, в сказку попал? Привыкай. WebForms дает максимум похожести на обычный десктоп.

Я догадываюсь, куда я попал, но хочу именно в сказку.
Мне не нравится, что весь граф обьектов живет только время обработки запросов, затем сериализуется, отправляется пользователю, потом снова десиарилизуется и т. д.
Эти приседания можно оправдать для очень большого числа пользователей.
Совершенно не ясно, зачем эти приседания, если пользователей мало и граф обьектов можно хранить в памяти все время сессии?
Быстродействие только увеличится — отсутсвует необходимость сериализации
Размер страниц уменьшится — никакой лишней информации кроме ID и версии формы там не будет нужно
Программу писать станет легче — исчезнет специфика веба.
Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....

IB>Правда есть другая альтернатива — Silverlight.
да, известно. Мне просто более интересно обсудить предыдущий подход.

Здравствуйте, Ziaw, Вы писали:



Z>А требование именно веб интерфейса чем продиктовано? Заставить веб приложение работать также как десктопное значительно труднее и сложнее в поддержке чем написать такое же, но в нормальном веб стиле. Реально выхода у вас два: вместо "сделать как в винформз" "сделать в winforms" или осознать преимущества stateless и набить руку в программировании веб интерфейсов. Если решите пойти вторым путем — откажитесь от webforms, они намеренно уводят в сторону statefull и постбеков. Попробуйте ASP.Net MVC, там stateless вполне органичен и удобен.

Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.
Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ...
Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.

Здравствуйте, Chrome, Вы писали:

C>Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.

Ну так сделайте стейтфул сервис на сервере который делает полезную работу и напишите к нему морду на винформсах.

C>Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ...
C>Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.

vedga

Здравствуйте, Chrome, Вы писали:

C>Я догадываюсь, куда я попал, но хочу именно в сказку.
Тогда тебе не в IT =)

C>Совершенно не ясно, зачем эти приседания, если пользователей мало и граф обьектов можно хранить в памяти все время сессии?
А какая разница? Тебе все равно придется на каждый запрос десериализовывать, а потом сериализовывать состояние обратно, не важно куда — сессия, вьюстейт, база, кеш... Количество приседаний от этого меняется слабо.
Более того, если использовать WinForms из коробки, то большинство приседаний он от тебя скроет, будет практически полная иллюзия десктопа. А конкретно с сессией есть масса чисто детских граблей, например, только из-за настроек веб-сервера у тебя может не быть гарантии, что следующий запрос от того же пользователя получит ту же сессию — тут как повезет.
Добро пожаловать в реальный мир — надоб просто учиться работать со stateless решениями, они вообщем-то даже проще, чем вин-формз, если разобраться.

C>Программу писать станет легче — исчезнет специфика веба.
Никуда она не исчезнет.

C>Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....
Это все иллюзии.

Здравствуйте, gandjustas, Вы писали:

G>Тут не в масштабируемости дело, а в том, что придется бороться с такими "простыми" спосбами, чтобы приложение с приемлимой скоростью работало.
Какой вопрос, такой ответ. Автор хотел как в десктопе — вот ровно как в десктопе он и получит.

Здравствуйте, Chrome, Вы писали:

C>Программу писать станет легче — исчезнет специфика веба.
C>Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....
Это фантастика. Специфика веба никуда не уходит. Можно поптыаться её скрыть, но это cильно нарушает привычний пользователям порядок работы веба.

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

ЗЫ. Statefull UI можно и на javascript сделать.

Здравствуйте, Chrome, Вы писали:

C>Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.
Здесь логический прыжок — описанные требования никак не ведут к именно веб интерфейсу.
C>Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ...
Потому, что HTML — это нихрена не Windows Controls. А HTTP — это не message loop.
Теоретически, можно замутить на аяксе архитектуру, аналогичную WinForms, и некоторые это даже делают. В результате получается плохая пародия на Remote Desktop.

C>Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.
А чем вас не устраивает Remote Desktop? Для описанной ситуации — самая та технология, что нужно.

Здравствуйте, Chrome, Вы писали:
C>Я догадываюсь, куда я попал, но хочу именно в сказку.
C>Мне не нравится, что весь граф обьектов живет только время обработки запросов, затем сериализуется, отправляется пользователю, потом снова десиарилизуется и т. д.

C>Эти приседания можно оправдать для очень большого числа пользователей.
Нет. К числу пользователей это не слишком относится. Это относится к тому, как работает протокол HTTP и стандартный веб-браузер.
C>Совершенно не ясно, зачем эти приседания, если пользователей мало и граф обьектов можно хранить в памяти все время сессии?

C>Быстродействие только увеличится — отсутсвует необходимость сериализации
C>Размер страниц уменьшится — никакой лишней информации кроме ID и версии формы там не будет нужно
Да, есть такая секретная техника в WebForms — хранение viewstate на серверной стороне.
C>Программу писать станет легче — исчезнет специфика веба.
Чтобы исчезла специфика веба, нужно убрать саму специфику веба. То есть эмулировать протокол RDP поверх HTTP. Совершенно непонятно, зачем это делать, когда для этих случаев есть RDP. Напоминает историю про мышей и кактус.
C>Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....

IB>>Правда есть другая альтернатива — Silverlight.
C>да, известно. Мне просто более интересно обсудить предыдущий подход.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Chrome, Вы писали:

C>>Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.
S>Здесь логический прыжок — описанные требования никак не ведут к именно веб интерфейсу.
C>>Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ...
S>Потому, что HTML — это нихрена не Windows Controls. А HTTP — это не message loop.
S>Теоретически, можно замутить на аяксе архитектуру, аналогичную WinForms, и некоторые это даже делают. В результате получается плохая пародия на Remote Desktop.

C>>Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.
S>А чем вас не устраивает Remote Desktop? Для описанной ситуации — самая та технология, что нужно.

Что то никак не удается направить разговор в нужное русло(((
я имею довольно высокую квалификацию касательно разработки веб приложений.
много знаю про браузеры, http, аякс, asp.net, flex и т. д. и т. п. За много лет излазил это дело вдоль и поперек.
Это я к тому, что большинство ответов — попытка просветить меня о существовании того, что мне известно — не интересно.
Интересно следующее. Мне абстрактно кажется, что существует ниша в разработке веб приложений —
приложения с небольшим числом пользователей — где можно применить немного другие подходы к архитектуре, и получить некоторые преимущества, среди которых — неинвертированная запись алгоритмов управляющей логики, отсутствие сериализации состояния при каздом запросе.
Привел пример приложения, вариации которого часто приходится писать — просто что бы стал понятен контекст, в котором видится полезным использование новой архитектуры. Ежу понятно, что и при помощи множества других архитектур можно реализовать эти требования.
Обсудить хочется саму предлагаемую архитектуру.

Вся логика, включая GUI, работает на стороне сервера.
Когда пользователь логинится — на сервере создается инстанс главной формы для данного пользователя — и хранится все время сессии — то есть пока пользователь не разлогинится. В клиентский браузер при каждом запросе отправляются только HTML модифицированных участков формы. ( То, что серверный код пометит каким нибудь методом InvalidateRegion). Управляющие воздействия пользователя диспетчиризируются соответсвующим контролам формы на сервере — и дальше в обработчики. В общем все как на десктопе. Если мы создали динамический контрол — он никуда не денется при следующем callback- будет существовать постоянно. Создали мы какую нибудь хитрую иерархию обьектов в runtime — не надо заботиться о ее сериализации — она спокойно будет жить все время сессии. Из потока управляющей логики спокойно можно вызвать MessageBox.Show или показать любой диалог, подождать пока пользователь ответит и продолжить выполнение потока.
Мне кажется, у этого подхода есть достаточно преимуществ.