Как вы решаете, должен ли проект быть сетевым или настольным? - PullRequest
14 голосов
/ 02 октября 2008

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

Я не знаю, будет ли кто-то еще заинтересован в этом приложении, и оно будет только для меня, поэтому я склоняюсь к настольному приложению. Если по какой-то причине я закончу его, выпущу его, и людям это действительно понравится, я мог бы также подумать о том, чтобы синхронизировать его с облаком (подумайте v2). Но я не уверен, насколько сложно сделать такое радикальное изменение, и я не хочу в конечном итоге получить что-то хорошее, бесполезное, потому что я сделал плохой выбор еще до того, как начал проект.

Есть ли какое-либо руководство для этого? Какие-нибудь практические правила или лучшие практики? Есть личный опыт?

Если язык имеет значение, я думаю о Java просто потому, что мне удобнее всего с ним, и это легко позволило бы мне поделиться им с друзьями для тестирования, и если я застряну и мне понадобится помощь кого-то еще в человек.

Ответы [ 10 ]

17 голосов
/ 02 октября 2008

Я обычно задаю несколько вопросов:

  • Может ли это быть сделано в Интернете? Я не так давно использовал компонент для редактирования изображений и должен был быть веб-приложением. Чтобы получить эту работу, потребовалось много усилий, и настольное приложение было бы гораздо лучшим способом.
  • Мне нужно будет получить к нему доступ из любого места? Да, вы можете загрузить его на флэш-накопитель, но в этом случае веб гораздо более осуществим.
  • Будет ли несколько пользователей? Это может пойти в любом случае, но «длинный хвост» обычно означает сеть.
  • Какие технологии вы хотите использовать? Последний и лучший интерфейс на основе WPF? Рабочий стол (да, да, silverlight, давай не будем там нормально?). Мозг мертвецов, глупый легкий пользовательский менеджмент Django или других? Web.
  • Если бы это было веб-приложение, нужно ли вам беспокоиться о распространенных векторах атак, таких как SQL-инъекция, XSS и т. Д.? У настольного приложения здесь тоже есть свои проблемы, но они менее подвержены риску.
  • Насколько это ресурсоемко? Убьют ли 10 пользователей производительность веб-сервера?
  • Управление версиями на рабочем столе может быть проблематичным, тогда как с веб-приложением все используют одну и ту же версию. Это может вас укусить, но вы можете увидеть, что новый пользователь Facebook отозвался.

EDIT:

  • Стоимость также может быть фактором. Веб-приложение с базой данных базы данных обычно означает веб-сервер. Если вы хотите придерживаться, скажем, Microsoft Stack, вам понадобятся лицензии на SQL Server, которые могут быть дорогими. Открытый исходный код дешевле, но может быть не во всех случаях. «Обслуживание» настольного приложения обычно обходится дешевле.
4 голосов
/ 02 октября 2008

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

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

При этом я видел несколько хороших веб-приложений.

4 голосов
/ 02 октября 2008

Если вы выпускаете как веб-приложение, вам не нужно будет переносить его. Вы также будете иметь доступ к нему, куда бы вы ни пошли.

3 голосов
/ 02 октября 2008

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

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

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

В конечном итоге это зависит от того, какое приложение вы хотите написать. Даже если вы создадите его как приложение для рабочего стола, вы можете позже переписать его для Интернета. Часто версия 2.0 программного обеспечения все равно требует почти полного переписывания.

3 голосов
/ 02 октября 2008

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

  • Какая у вас аудитория? Есть ли у вас контроль над ними?
  • Насколько сложны взаимодействия, которые вы ожидаете реализовать?
  • Требуется ли обновление данных в режиме реального времени?
  • Как часто вы ожидаете обновить приложение после первого выпуска?
  • Ожидаете ли вы четко определенного набора клиентских платформ или не можете предсказать это?

Обратите внимание, что ваш выбор также может включать приложение Java WebStart, которое устраняет некоторые недостатки типичного настольного приложения.

1 голос
/ 02 октября 2008

Два важных вопроса, которых пока нет в списке:

  • Будет ли в первой версии какие-либо функции, требующие низкоуровневого доступа к оборудованию?
  • Будут ли в будущих версиях какие-либо способности, требующие низкоуровневого доступа к оборудованию?

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

1 голос
/ 02 октября 2008

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

1 голос
/ 02 октября 2008

Иногда сеть может быть хорошей, а иногда нет. Мы находимся в новой волне, которая идет в сети, но не забывайте несколько вещей:

  • Графический интерфейс в Интернете более сложный из-за нескольких браузеров
  • Людям, которым нужно работать в вашей системе, может не нравиться работать целый день в браузере
  • Интернет может работать медленнее для некоторых приложений (редактирование изображений, тяжелая работа, требующая много ресурсов процессора)
  • Rapid Gui, как Visual Studio для winform, быстрее, чем для веб

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

0 голосов
/ 02 октября 2008

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

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

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

0 голосов
/ 02 октября 2008

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

...