Пожалуйста, расскажите или где можно почитать про фундаментальные различия в архитектуре разработки Web и Десктопных приложений?

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

Вот

Автор:
Дата: 19.05.13

что-то похожее недавно проскальзывало. Об информативность и
содержательности дискуссии судить не берусь.

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

P>Пожалуйста, расскажите или где можно почитать про фундаментальные различия в архитектуре разработки Web и Десктопных приложений?

Десктоп это всегда
рич UI => мега-фреворки для UI, при чем UI обычно более навернутые чем самые навернутые рич вебстраницы
вагон функционала самой разной направлености
высокие требования к времени отклика
работа с файловой системой
интеграция с существующими приложениями
интеграция в систему
куча самых разных вещей, типа полнотекстового поиска, хитрого рендеринга — все пилится или руками и/или с привлечением мега-фремворков
состояние хранится локально и объемы данных которыми пользуется приложение могут ужасать,
базы данных часто не используются в силу ряда причин
Часто требуется поддержка конфигурационных файлов и возможностей скриптинга
часто однопоточные , апи часто синхронный
могут выюзывать чуть не всю доступную память
кроссплатформенность большей частью отсутсвует
требования к безопасности большей частью отсутствуют
требуют адский инсталятор
Архитектура очень часто строится в виде MS Office-like model или Automation Model или Bus и тд. Чтото навроде можно глянуть здесь http://www.codeproject.com/Articles/11163/Developing-Next-Generation-Smart-Clients-using-NET

Веб приложения в основном это всегда или почти всегда
показ контента
большей частью весь фукнционала навроде "на сервере склеить текст html( xml, json) из разных источников и отдать клиенту, на клиенте показать испльзуя html, сss и JS"
работа с базой данных — состояние там и хранится
многопоточные
сильно ограничены в ресурсах и требования к нагрузке очень высокие
к времени отклика не сильно критичны
рич есть и он всегда слабоватый
запускаются во всех браузерах
высокие требования к безопасности
скриптинга нет, конфигурация сильно урезаная
интеграция с другими приложениями весьма слабая
актуально кеширование
сложность UI на уровне сложности отдельной формочки для десктоп приложения
асинхронщина на клиенте и сервере — обычное дело
В качестве архитектуры берется обычно варианты MVC

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

P>Пожалуйста, расскажите или где можно почитать про фундаментальные различия в архитектуре разработки Web и Десктопных приложений?

Фундаментальное различие для разработчика — это работа с состоянием. У GUI оно целиком внутри приложения, у Web шарится между клиентом и сервером. Остальное — суета.

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

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

P>>Пожалуйста, расскажите или где можно почитать про фундаментальные различия в архитектуре разработки Web и Десктопных приложений?

IT>Фундаментальное различие для разработчика — это работа с состоянием. У GUI оно целиком внутри приложения, у Web шарится между клиентом и сервером. Остальное — суета.

Примерно такого ответа я и ожидал. Теперь вопрос как это называется — Service statelessness principle?

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


P>Примерно такого ответа я и ожидал. Теперь вопрос как это называется — Service statelessness principle?

Это для SOA.
Возможно, кстати, и для REST архитектур.

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

IT>>Фундаментальное различие для разработчика — это работа с состоянием. У GUI оно целиком внутри приложения, у Web шарится между клиентом и сервером. Остальное — суета.

P>Примерно такого ответа я и ожидал. Теперь вопрос как это называется — Service statelessness principle?

Там же написано как это назвается. Да и к вопросу это имеет мало отношения. Приложений, в которых можно извести состояние в ноль — мильён. Например, любая репортинговая система или потреблялка контента может быть таковой. С другой стороны из всевозможных редакторов, ентри тулов, систем, отображающих состояние в реальном времени, убрать состояние никак не получится, т.к. работа с состоянием и есть их главная задача. Впрочем, элементы обоих типов приложений можно найти практически в любой программе. Так вот, как только мы касаемся состояния, так сразу и начинаются различия.

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

IT>Там же написано как это назвается. Да и к вопросу это имеет мало отношения. Приложений, в которых можно извести состояние в ноль — мильён. Например, любая репортинговая система или потреблялка контента может быть таковой. С другой стороны из всевозможных редакторов, ентри тулов, систем, отображающих состояние в реальном времени, убрать состояние никак не получится, т.к. работа с состоянием и есть их главная задача. Впрочем, элементы обоих типов приложений можно найти практически в любой программе. Так вот, как только мы касаемся состояния, так сразу и начинаются различия.

Хорошо, тогда где можно почитать про принципы, которыми нужно руководствоваться при разработке веб, в отличие от декстоп? Т.е. именно, как работы с "состоянием"...