Как Вы решаете, должен ли проект быть веб-или основан на рабочем столе?
Есть некоторые проблемы, которые вы должны рассмотреть:
- теоретически, он может содержать рекурсивную цепочку. 2 или более объекта являются родителями друг друга.
- При сортировке и перемещении родительского объекта он должен обновить все свои дочерние объекты.
Поэтому, я думаю, единственный эффективный способ - это перевести его в граф (многодетное дерево) с указателями вместо индексов.
struct Object2
{
void* data;
Object2* FirstChild; // Will point to first child (if there is), or null.
Object2* NextSibling;// Will point to next sibling (if there is), or null.
};
На самом деле, вы можете использовать любую библиотеку XML для сортировки:
- Любой дочерний элемент просто необходимо добавить к родительскому элементу.
- Когда вы закончите, вы читаете элементы из XML и переупорядочиваете новые индексы.
10 ответов
Я обычно задаю несколько вопросов:
- это может даже быть сделано в сети? Что-то, что я не сделал слишком долго назад, включило компонент редактирования изображение и должно было быть веб-приложением. Это включило много боли для получения этой работы, и настольное приложение будет намного лучшим способом пойти.
- я должен буду получить доступ к нему откуда-либо? Да Вы могли загрузить его на карте флэш-памяти, но сеть намного более выполнима в этом случае.
- там будут многочисленные пользователи? Это могло пойти так или иначе, но "длинный хвост" материал обычно означает сеть.
- , Какую технологию Вы хотите использовать? Последний и самый большой WPF основывал UI? Рабочий стол (да да, Silverlight, позволяют нам не пойти туда хорошо?). Глупое глупое легкое управление пользователями Django или других? Сеть.
- , Если это было веб-приложение, необходимо ли будет волноваться об общих векторах атаки как Внедрение SQL, XSS, и т.д.? Настольное приложение имеет свои собственные проблемы здесь также, но будьте склонны иметь меньше воздействия.
- , Насколько интенсивно использующий ресурсы это? 10 пользователей уничтожат производительность веб-сервера?
- Управление версиями на рабочем столе может быть болью, тогда как с веб-приложением все находятся на той же версии. Это может укусить Вас, хотя, посмотрите Нового пользователя Facebook pushback.
РЕДАКТИРОВАНИЕ:
- Стоимость может быть фактором также. Веб-приложение с бэкендом базы данных обычно означает веб-сервер. Если Вы захотите придерживаться, скажем, Microsoft Stack, то Вам будут нужны лицензии на SQL Server, который может стать дорогим. Открытый исходный код является более дешевым, но не может быть опцией во всех случаях. "Обслуживание" настольного приложения является обычно более дешевым.
Если Вы выпускаете как веб-приложение, Вы не должны будете портировать его. У Вас также будет доступ к нему везде, куда Вы идете.
Я основываю свой выбор на GUI главным образом. Если GUI будет быть сложным, и (должно быть быстрым или будет иметь аспекты его, которые займут много времени для обработки), затем, то я пойду с Рабочим столом. Если это будет просто, и будет всегда иметь небольшие наборы данных для работы со сразу, то я пойдет с сетью.
я работал над приложением, которое было сделано как веб-приложение, когда ясно оно лучше подошло для рабочего стола. Это был крупный отказ. Я не знаю, КАК клиенты выносят его, вызывают, я, конечно, не использовал бы его. Настольная версия (который принял 6 месяцев для переписывания) унесла веб-версию из воды.
Однако я видел некоторые хорошие веб-приложения.
Все, что я могу предложить, является несколькими факторами, которые были бы соответствующими. Как Вы определяете ответ, и вес для фактора ваше дело и другие обстоятельства:
- , Какова Ваша аудитория? Вы имеете какой-либо контроль над ними?
- , Насколько сложный взаимодействия, которые Вы ожидаете реализовывать?
- Вы требуете обновлений данных псевдореального времени?
- , Как часто Вы ожидаете обновлять приложение после первого выпуска?
- Вы ожидаете четко определенный набор клиентских платформ, или разве Вы не можете предсказать это?
Примечание, что Ваш выбор также может включать приложение Java WebStart, которое смягчает некоторые недостатки типичного настольного приложения.
Мой выбор по умолчанию состоит в том, чтобы пойти с веб-решением, поскольку легче развернуться и обычно многоплатформенный. Единственное время я иду с приложениями winforms, - когда там нажимают безопасность, производительность или проблемы функциональности, которые требуют его.
Когда-то сеть может быть хорошей и когда-то нет. Мы находимся в новой волне, которые входят в сеть, но не забывают немного вещей:
- GUI в сети более сложен из-за нескольких браузер
- Люди, которые должны работать над Вашей системой, не мог бы любить работать целый день в браузере
- , сеть может быть медленнее для некоторого приложения (редактирование изображение, трудная работа, которые требуют большого количества ЦП)
- Быстрый Gui как Visual Studio для winform быстрее, чем для сети
, Но сеть имеет преимущество в deployement и в мобильности. Если Ваша система хорошо структурирована, Вы могли бы сделать обоих или изменить на одного к другому позже с чем-то сборку с MVC. Просто измените свое визуальное, и Вы будете в порядке.
Два важных вопроса не в списке до сих пор:
- первая версия будет иметь какие-либо функции, которые должны lowish-выровнять доступ к аппаратным средствам?
- Будет будущее , версии имеют какие-либо функции, которые должны lowish-выровнять доступ к аппаратным средствам?
довольно легко ответить на первое, но предоставление второго некоторой мысли может сохранить Вас некоторая головная боль в будущем.
Если это было приложением, которое будет использоваться мои многочисленные пользователи с совместно используемыми данными, Вы, вероятно, собираетесь хотеть сервер так или иначе. В этом случае я склонился бы к веб-приложению. Иначе у Вас есть сложность синхронизации данных между рабочим столом и сервером.
Я сказал бы, что большинство приложений должно быть основано на рабочем столе. Преимущества быстрее и больше жидких приложений.
необходимо только создать веб-приложение, если существуют очевидные преимущества от него, как доступ отовсюду. (Если это необходимо для Вашего приложения.)
оборотная сторона А веб-приложений может также быть то, что это зависит от разработчика при выходе из поддержки всего этого пользователи (если у Вас будет кто-либо), не может больше использовать его. Кроме того, существует шанс, что пользователи не готовы хранить свои данные онлайн.
В конечном счете это зависит от того, какое приложение Вы хотите записать. Даже при создании его как настольного приложения можно позже переписать его для сети. Часто 2,0 версии потребностей программного обеспечения почти завершают перезапись так или иначе.
Ранее Вы записали бы настольное приложение, поскольку инструмент был лучше для этого, и Вы запишете это быстрее. Люди раньше хотели веб-приложения, но всегда заканчивали с рабочим столом.
В наше время вещи отличаются, можно записать веб-сервис столь же быстро и легко таким образом, нет никакой причины не пойти веб-.
преимуществами веб-является гибкость, масштабируемость и простота развертывания. Это не будет столь быстро реагирующим, как настольное приложение могло быть, но это не большая часть проблемы, если Вы думаете о своем дизайне.