Каковы преимущества и проблемы разработки веб-приложений по сравнению с настольными приложениями?
РЕШЕНИЕ
Я решил следующим образом:
<?php
for($i = 1; $i < 10; $i++){
/* BEGIN: SOLUTION */
// Read/Clean buffer until isn't empty
while(stream_select($read = [STDIN], $write = [], $except = [], 0)){
fgets(STDIN);
}
/* END: SOLUTION */
$read = readline("Question $i: "); // Look at the number
echo "Your answer is: " . $read . PHP_EOL;
sleep(2); // Now on execution try press ENTER one ore more times
}
14 ответов
В большинстве случаев разработка веб-приложений намного проще и делает одну из больших проблем - развертывание и развертывание новых версий, исчезновение.
Вам не нужно иметь дело с разные версии операционной системы, установленные библиотеки, реестр, COM и т. д. Вы имеете дело с разными браузерами, но это гораздо меньше.
Я не могу представить развертывание настольного приложения на 2-3 миллионах клиентов каждый месяц - то, что хорошо работает с веб-сайтами.
Поскольку разработка идет вместе с веб-разработкой, у вас есть:
- более короткие пути выполнения
- меньше состояния для управления
- , вам вряд ли придется иметь дело с параллелизмом самостоятельно
- гораздо меньше ресурсов или нет ресурсов для управления - не обрабатывает ОС
Единственным недостатком является то, что для настройки компьютера разработки обычно требуется больше, а отладка веб-приложений была более сложной.С текущим состоянием инструментов отладка больше не является проблемой.
Поэтому всегда предпочитайте веб-приложение, если это возможно.
Большинство ответов (пока что так или иначе), похоже, сосредоточены на том, насколько простым или сложным будет выбор. Вся цель приложения, как настольного, так и веб-ориентированного, состоит в том, чтобы обслуживать конечного пользователя. Что должно быть отправной точкой обсуждения.
Веб-приложения просто не могут обеспечить такой же богатый и интерактивный интерфейс, как настольное приложение в большинстве случаев. Ограничений слишком много из-за доступных виджетов, задержки в сети, того факта, что окно вашего приложения (как правило) должно (как правило) находиться в другом приложении и т. Д.
При этом интерфейсам часто не требуется большой набор виджетов. сетевая задержка не является большой проблемой, и запуск из окна браузера является преимуществом. Gmail и переполнение стека являются яркими примерами веб-приложений, которым не нужен особенно богатый интерфейс.
Итак, при попытке решить, какую технологию использовать, сначала учитывайте пользователя. Им нужен высокопроизводительный, богатый пользовательский интерфейс? Нужно ли им иметь возможность легко делиться своими данными с другими людьми в сети? Это приложение, которое они будут использовать восемь часов в день или просто случайно? Будут ли они использовать его в основном для редактирования локальных файлов или для совместной работы с людьми по сети?
Для тех, кто говорит, что «веб-приложения всегда лучше», позвольте мне задать вам вопрос: подумайте об инструментах, которые вы используете каждый день. Ваш текстовый редактор, программирование IDE, ваш браузер, ваш почтовый клиент. Какие из этих веб-приложений? Вероятно, нет, за исключением, может быть, вашего почтового клиента. Есть причина, по которой вы не хотели бы использовать сетевую среду разработки для написания программного обеспечения (или для написания книги, или для серьезных манипуляций с изображениями).
Все сводится к пользователю и его целям. Иногда их потребности лучше всего удовлетворять веб-интерфейсом, иногда - настольным. Иногда либо подойдет. Конечно, вам также необходимо взвесить такие параметры, как распространение и обновление, кроссплатформенность и т. Д., Но все начинается с пользователя и его целей. Если вы сосредоточены на удовлетворении своего конечного пользователя, ответ, скорее всего, станет довольно очевидным.
IMHO Web Develoment более напряженный ... вы должны бороться с Internet Explorer за несоответствие стандарту, медленное соединение, странное поведение css, эксплойт браузера.
Я считаю, что веб сложнее, вам нужно беспокоиться о состоянии, сети и уделять больше внимания таким вещам, как загрузка, безопасность, список можно продолжать. Как насчет кошмара, который совместим с браузерами, AJax, CSS arrghhh.
OTOH Поскольку у рабочего стола меньше границ, может быть, дизайн немного сложнее, поскольку у вас больше возможностей - хотя я с этим не согласен.
Я думаю, что у каждого есть свои огромные сложности, которые делают их уникальными вызовами, и вы получите другой ответ в зависимости от того, кого вы спрашиваете. Веб-программисты могут подумать, что настольные приложения сложнее, чем веб-проекты, просто из-за незнания среды.
Люди, работающие в настольных системах, могут обнаружить, что веб-приложения гораздо сложнее кодировать, потому что им приходится принимать во внимание гораздо больше проблем проектирования с CSS и связью с использованием протоколов AJAX.
Существует довольно много различий между ними, которые создают проблемы или выгоды. Для веб-приложений:
- State - HTTP-запросы не имеют состояния и должны управляться путем передачи переменных сеанса через все запросы или файлы cookie. Это накладные расходы в веб-приложениях, и ASP.NET часто подвергается критике из-за огромных пятен данных сеанса.
- Централизованный - Внесение изменений в веб-приложение так же просто, как обновление битов на сервере по сравнению с настольным компьютером приложения, где патчи должны быть развернуты для всех пользователей. Централизованная природа также облегчает аналитику и тому подобное. Это большое удобство. Я помню, GMail однажды исправил дыры в безопасности менее чем за 4 часа. В отличие от этого, все еще существует множество уязвимых машин без исправлений Windows.
- Архитектурный - толстый сервер, тонкие клиенты делают платформу веб-приложений независимой. Это также помогает в управлении балансом ... например, сортировку таблиц, проверку ошибок, математические вычисления или графику (например, в случае с флэш-памятью) можно выполнять на клиенте или сервере в зависимости от распределения ресурсов. Из-за тонкого клиента это означает, что можно полностью перестроить сервер, не оказывая влияния на клиента вообще. Такой уровень гибкости действительно удобен.
- Безопасность - Настольные приложения работают в доверенной среде, где они могут делать все, что угодно, так как веб-приложения работают в изолированной среде, что делает их по своей природе более безопасными для клиента , Тем не менее, веб-приложения требуют некоторого количества конфигурации, поскольку это относится к сертификатам, элементам управления ActiveX и так далее.
- Управление версиями - Стоимость версий намного выше для настольных приложений. Это восходит к более утомительному процессу выталкивания изменений. И, опять же, скачок номеров основных версий означает увеличение дохода за счет обновления пользователей. В веб-приложениях управление версиями в основном предназначено для самих разработчиков, и гораздо проще выполнять небольшие итеративные улучшения. Вот почему настольные приложения по-прежнему придерживаются цикла разработки «водопада», потому что внесение изменений стоит дорого, и вы должны получить его с первого раза. Настольные приложения также имеют стоимость обратной совместимости, такую как поддержка Windows 98, XP и Vista или поддержка более старых процессоров, драйверов и т. Д.
- Среда - веб-приложения работают в предсказуемой среде, что опять-таки очень удобно.
Я очень сомневаюсь, что веб-программистам нужно знать winapi. Я говорю, что программирование GUI требует больше времени для изучения.
Веб-разработка сложнее в моем опыте, вам нелегко поддерживать состояние легко; Кроме того, вам приходится иметь дело с проблемами форматирования (CSS отлично, но это трудно освоить).
Я получаю работу как на своей повседневной работе, так и могу честно сказать, что единственная веская причина для разработки настольного приложения заключается в том, что пользователь не будет подключен постоянно.
Распространение / поддержка настольного приложения имеет проблемы, которые всегда зависят от пользователя, в то время как веб-приложение может быть отлажено без какого-либо участия пользователя. Это никогда не должно быть сведено к минимуму, так как может потребоваться чрезмерное количество времени для отладки дефекта, который есть у одного пользователя в Айдахо, которого нет у другого пользователя.
Развитие этих двух процессов требует разного менталитета. Веб не имеет состояния по своей природе, а рабочий стол - полный. Когда я переключаюсь между ними, я часто расстраиваюсь, потому что я привыкаю к одному, а затем пробую тот же самый шаблон / технику в другом, и он терпит неудачу. Если вы можете' т веб-сервер не работает, тогда ваши возможности ограничены. Если вы хотите, чтобы пользователи использовали его в западных штатах Вирджинии, у вас есть несколько вариантов.
Дополнительная информация в вопросе поможет, так как этот вопрос слишком широк, чтобы его охватить.
С настольными приложениями вам не нужно решать такие проблемы, как состояние приложения, так же, как в Интернете. HTTP - это протокол без сохранения состояния, поэтому разработчик должен определить, как поддерживать текущее состояние приложения для сеанса пользователя. Рабочий стол может использовать TCP / IP и поддерживать соединение с сервером.
С помощью Интернета очень легко создать привлекательный пользовательский интерфейс, так как вы можете добавлять анимацию с помощью Javascript, Flash и т. Д. Это больше работы для разработчика, когда приложение ориентировано на данные, а состояние приложения является проблемой.
Ух ты, я пока удивляюсь ответам. Я занимался обоими, настольным компьютером в прошлом и почти всем вебом. Я считаю, что веб-разработку гораздо проще разрабатывать, гораздо проще поддерживать и намного проще развертывать и развертывать.
Я бы никогда не выбрал разработку чего-либо на рабочем столе, если бы вместо этого была возможность сделать это в Интернете.
Настольные приложения - это путь. Текущая веб-технология (HTML, Javascript, HTTP, ...) никогда не была разработана с учетом приложений. Он был разработан для документов. И вы чувствуете это с каждой строкой кода, которую вы пишете.
Все зависит от:
- Какой у вас опыт разработчика?
- Какой тип приложения вам нужно делать?
А также - что вы называете веб-приложениями? Приложения Silverlight или Flash могут быть сделаны таким образом, что вы можете использовать его с рабочего стола или из браузера. Ajax-приложения сегодня не сильно отличаются от настольных приложений, но гораздо сложнее разработать что-то не слишком простое с DHTML (даже если вы берете такие фреймворки, как jQuery или даже GWT).
Предполагая HTML или DHTML в качестве веб-приложений:
Я провел много лет в разработке web / ajax и десктопов, и мой опыт такой же - я сделал кучу сложных веб-приложений и десктопов. Имея хороший инструментарий и инструменты для C # и достаточный опыт, я могу создать лучшее настольное приложение, чем веб-приложение, за тот же или более короткий период времени. Второй момент может быть охвачен приложениями Silverlight / Flash (которые я рассматриваю как настольные). Третий может быть сделан для RIA, но требует некоторых усилий (то же самое относится и к приложениям ajax).
Если вы нацелены на что-то простое и не знаете современных инструментов и методов разработки для настольных компьютеров / RIA, которые могут быть еще одной веской причиной для разработка веб-приложения. Но, как я уже сказал - надеюсь, это будет что-то простое.
Оба типа приложений имеют свои преимущества и недостатки. например, веб-приложениям может потребоваться учитывать разные браузеры, и получить полезный пользовательский интерфейс в сети сложнее, чем в формах Windows. Тем не менее, веб-приложения тоже имеют некоторые преимущества. Первое, что приходит на ум, - это развертывание, и не нужно беспокоиться о разных платформах (только о разных браузерах - да, сложнее разрабатывать для разных платформ, чем для разных браузеров).