Hi, All!

Собственно, сабж. Вопрос философский. Какие плюсы и минусы?

С одной стороны обычное инсталлируемое на все клиентские локальные машины приложение (WinForms, WPF, Delphi, MFC и т.д), которое работает с базой данных на сервере.

С другой - веб сервер (IIS, Apache) и приложение (на C#, PHP, Java и т.д.), работающее с базой, а на клиенте только браузер.

Мне кажется, что решение в виде Web-приложений более сложно в реализации и тестировании, более глючно.

Аргументы:

Постоянно приходится искать (делать самому или покупать) самые примитивные контролы. Тот-же TreeView, ListView, Splitter, которые были в WinAPI со времен Win95, потом были обернуты в MFC, WinForms. В стандартной поставке Visual Studio 2008 нет Web-контролов, аналогичных им по функционалу.


Совместимость с разными браузерами. Уже давно является типовой ситуация, когда для работы с сайтами разных компаний приходится держать на машине несколько браузеров нескольких версий. Одни работают только с IE6+ (причем, после недавнего обновления на IE8 сайт начал глючить и пришлось откатить обновление), другие только FireFox, третьим оперу подавай. Для разработчика добиться совместимости со всеми версиями всех браузеров очень сложно. Не менее сложно тестирование таких решений.


Идея "тонкого клиента" провалилась. Все идет к созданию операционной системы, работающей из браузера. Началось все с JVM, теперь SilverLight, Flash/Flex.

Так в чем смысл клепать интерфейсы на DHTML/CSS, прикручивать AJAX, изучать разработку под SilverLight и воссторженно писать в блогах, что удалось изобрести контрол, который был в винде еще 10 лет назад?

РеалистА Вы попробуйте НЕ использовать продукты микрософт. ;-)От этого что-то фундаментально изменится? Возрастет стабильность работы приложений и их совместимость? Рядовые юзера все равно в большинстве на винде и под IE. Есть сайты, которые громко орут, что у них хром и сафари. Юзер поставит себе сафари. Но не снесет IE, т.к. некоторые сайты работают только под IE.

mcureenabЭто модно.Хороший аргумент. И, похоже, единственный.

mcureenabЕщё всё стремится к унификации, чтобы любая программа могла работать где угодно.Это было достигнуто еще во времена UNIX. Достаточно написать на C/C++ POSIX совместимое консольное приложение и оно будет работать где угодно. Я для диплома писал большой пакет вычислительных программ, который работал под:

Intel 286, Dos16, компилировался Borland C++ 3.1.

Intel 386, Linux, компилировался GCC.

Intel 486, Dos32 с расширителем DOS4GW, компилировался Watcom C++ 10.0.

Intel 486, Win16, компилировался MS Visual C++ 1,5.

Intel 486, Win32, компилировался MS Visual C++ 4.0.

Pentium IV, Win64, компилировался MS Visual Studio 2008.

SUN, Solaris, компилятор не помню.

CRAY Y-MP C90 (это такая скамейка с жидкостным охлаждением), UNICOS, компилятор не помню.

SGI Indigo2, IRIX, компилятор не помню.

Потом появилась Java, которая декларировала все те-же возможности и создавалась с той-же целью.

А идеологию "тонкого клиента" мы проходили еще во времена больших ЭВМ и терминалов.

mcureenabДома имею PC под Windows Vista, PC по Windows XP и Mac под Mac OS X. А теперь попробуй сделать программу, которая работает на каждой платформе.На каждой платформе еще куча браузеров. Сделать программу, работающую под каждым браузером, не менее сложно. Все равно такая программа будет состоять из общего кода и кода, специфичного для платформы (вопрос лишь в процентном соотношении). Если я пишу на C++, я просто использую директивы условной компиляции и получаю разные исполняемые файлы под каждую платформу. Если я пишу на интерпретируемом языке, типа JavaScript, у меня может быть один скрипт на все платформы, но при его запуске все равно определяется тип платформы и далее в случае необходимости исполняются разные ветки кода для разных платформ.

Можно использовать исключительно возможности стандартных библиотек Java. Тогда с высокой вероятностью программа будет одна для всех платформ.

Вместо подключения браузером к веб-приложению, работающему на сервере, можно терминальным клиентом подключиться к рабочему столу сервера и запустить там обычное GUI-приложение. Бездисковые рабочие станции, которые грузят, к примеру, Linux в оперативку и подключаются к виндовому серверу - чем не архитектура?

NarotoNaroto так и не поняло - Вы занимаетесь риторическими изысканиями или всёжтки ищите ответ на свой вопросМне интересны аргументы в пользу тех или иных архитектурных решений.

NarotoФишка разработки в том что нужно клиенту. Десять лет назад клинету надо было одно, сегодня - совсем другое. Через 10 лет - уже третье.Клиент выбирает архитектуру? Вы думаете, ему интересно, на каком языке оно написано, какие паттерны использованы и что там внутрях? Скажите клиенту, что у Вас наноархитектура и нанопротоколы. И он поверит и купит. Это сейчас модно.

NarotoНа сегодня да - вэб это удобно, практично легко и дёшево.Вот в этом как раз и сомнения.

kmawА для меня более интересен другой аргумент в пользу веб. Если пользователей много и они географически разбросаныОни скачают и поставят обновления. Можно автоматизировать этот процесс. Тот-же msi можно доменными политиками автоматом поставить на все рабочие места в компании.

kmawто сопровождение и всякие прелести с этим связанные гораздо проще и менее трудозатратны для веб-системНе сталкивались с вариантом "а у меня браузер падает"? Все, что Вам остается, убедить клиентов подождать, пока производитель браузера пофиксит очередную багу в браузере, связанную с утечками памяти. А при обновлении на новую версию браузера никогда ничего не падало?

kmawЕсли при этом система имеет статус корпоративной, то проблем с кроссбраузерностью вообще нет - все ДОЛЖНЫ пользоваться каким-то определенным браузером (это не так уж и сильно обламывает пользователей).А они только на корпоративный сайт лазят? У меня пример: для работы человеку надо пять сайтов разных компаний. Они требуют четыре разных браузера (IE 6.0, IE 7.0, FireFox, Opera).

kmawда и кроссбраузерная верстка и JavaScript не проблема на самом деле - распространенных браузеров не 10000, а 3-4.Операционных систем тоже не много. По крайней мере гугль еще не взялся за разработку и продвижение своей операционки. Даже Mac OS в основе содержит BSD. Так что речь идет только о двух системах: о винде и о юниксах.

kmawА вот заставить толстого клиента нормально работать на всех рабочках пользователей, которые постоянно настраивают какие-то свои параметры, устанавливают ПО и т.п. гораздо геморнее.Это пока в браузерах не так много настроек. По мере роста количества наворотов, настроек и разных плагинов (которые пользователи постоянно устанавливают откуда попало) все быстро перестанет работать. Вышел IE8 запараноенный по безопасности и рубящий все, что ему кажется подозрительным, и попробуйте все эти предупреждения у него отключить.

kmawКонечно, ели толстый клиент действительно необходим, то пытаться его имитировать всякими там AJAX и прочими модными фишками неправильно.А он практически всегда необходим, если функционал посложнее простого форума.

mcureenabЧем компилировать код на мобильном телефоне? А java приложения на нём работают.Код можно компилировать на том, на чем работает компилятор. Java тоже компилируется, хоть и в промежуточный код. В любом случае нужна проверка синтаксиса компилятором и выявление банальных багов. И чем лучше в этом помогает компилятор и структура языка, тем оно надежнее. Потому я не люблю JavaScript, PHP и прочие скрипты, где баги всплывают только в момент исполнения кода.

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

mcureenabКроме того есть портативные устройства, типа PDA или телефонных WAP браузеров, в них размер экрана и безмышевость огранияения налагает. Тем не менее не так уж сложно сделать HTML код, который и на HD панели и в телефончике будет читаемым и привлекательным.Лучше сделать два варианта, потому как решения для сложного пользовательского интерфейса будут сильно отличаться в этих случаях. Независимо от того, на чем реализовано приложение. Для обычного ОО-языка я могу заюзать паттерн "абстрактная фабрика", который поможет создать тот или оной GUI при запуске, в зависимости ит контекста. В случае HTML я бы сделал единый XML и два разных XSLT, которые генерят один HTML для монитора, другой для телефона.

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

trdm:) майкрософт, майкрософт, майкрософт....
пошарься в этом блоге: http://habrahabr.ru/blogs/webdev/
много нового узнаешь, например о http://habrahabr.ru/blogs/jquery/
а надеяться на майкрософт - останешся голодным.Про хабру я знаю. Вот только хочется стандартный инструмент, в котором был-бы набор стандартных контролов, а не собирать каждый раз мозайку самому. Хочется окно, где слева дерево, а справа список. И чтобы сплиттер между ними, размеры менять. В списке, понятно, мышкой размеры колонок менять, менять колонки местами и по щелчку мышки на хедере колонки сортировать список. И чтобы мышкой контролы на форму бросил, обработчики событий написал и запустил полюбоваться. Почему для этого я должен знать DHTML, DOM, JavaScript, XML, SXLT, кучу библиотек, типа jQuery и расковыривать внутреннее устройство этого счастья, чтобы понять, как к своей задаче прикрутить и заставить один контрол на форме реагировать на события другого контрола? "это удобно, практично легко и дёшево"? Если 10 человек знают WinForms и Visual Studio, то они прекрасно поймут друг-друга. Если в команде 10 человек и каждый привык к своей любимой реализации календаря или любого другого контрола, то это уже не команда.