Наша команда разделена по этому вопросу, и я хотел бы получить некоторые сторонние мнения.
Мы создаем приложение и не можем решить, хотим ли мы использовать .Net WPF Desktop Application с сервером WCF или веб-приложение ASP.Net с использованием jQuery. Я думал, что задам вопрос здесь, с некоторыми спецификациями, и посмотрим, каковы будут плюсы / минусы использования любой из сторон. У меня есть свой любимый и чувствую, что я предвзят.
В идеале мы хотим построить первоначальный выпуск программного обеспечения как можно быстрее, а затем замедлить работу и потратить время на внедрение дополнительных функций / компонентов, которые нам понадобятся позже. Прежде всего, мы хотим, чтобы программное обеспечение было быстрым. Пользователи просматривают записи в течение всего дня, а задержки в загрузке записей или обновлении экранов снижают их производительность.
Детали приложения:
- Я оцениваю около 100 различных экранов для первоначальной версии, а планы для многих дополнительных экранов будут добавлены позже после первого выпуска.
- Мы стремимся использовать двустороннюю связь для систем напоминаний и событий
- В настоящее время приходится поддерживать около 100 пользователей, хотя нам сказали, что необходимо обеспечить рост до 500 пользователей.
- У нас есть несколько мест
Вопросы для рассмотрения (может быть, не изначально в некоторых случаях, но в будущих выпусках):
- Место для дополнительных компонентов, которые будут добавлены после первоначального выпуска (их много ... возможно, они здесь работают, чем первоначальное приложение)
- Клавиатурная навигация
- Производительность является обязательным
- Скорость производства до начальной версии
- Низкие эксплуатационные расходы
- Будущая поддержка
- Интеграция софтфона / сканера
Наши разработчики:
- У нас есть 1 программист, который изучал WPF в последние несколько месяцев и был тем, кто предложил использовать WPF для этого.
- У нас есть второй программист, который знаком с ASP.Net и может помочь с проектом в будущем, хотя он не будет работать над ним до первоначального выпуска, так как он тратит время на обслуживание нашего текущего программного обеспечения.
- Есть я, который работал с обоими и мне комфортно в любом
- У нас есть внешняя компания, занимающаяся управлением проектами, и они являются компанией ASP.Net.
- Мы планируем нанять 1-2 других, однако нам нужно знать, в каком направлении мы идем в первую очередь
Среда:
- Обычные пользователи находятся на сервере Windows 2003 с Terminal Services. Они подключаются с помощью тонких клиентов WYSE через соединение RDP. Административный персонал имеет свои ПК с XP или выше. Пользователям разрешено указывать свое собственное разрешение, хотя они ограничены использованием IE в качестве веб-браузера.
- Другие местоположения подключаются к нашей сети через соединение MPLS
Исходя из этого, что бы вы выбрали и почему?
Ответы:
Это, безусловно, звучит для меня как приложение WPF, с большим количеством взаимодействия с пользователем и потенциально взаимодействия с оборудованием. Вы можете доставить приложение с помощью Click-Once, поэтому развертывание в основном не является проблемой. Ваше приложение WPF может получить доступ к службе WCF и доставлять данные в двоичном виде, поэтому производительность будет превосходной. Я бы начал читать на WPF и познакомиться с ним как можно скорее.
источник
Сумасшедший бахромой ответ: оба. Правильный уровень обслуживания. Легко иметь толстый клиент, который делает все (WPF), и быстрый веб-клиент, который делает самые обычные вещи (ASP.NET). Оставьте дверь открытой для мобильного клиента и т. Д. В будущем.
источник
Если у вас есть только один программист, который изучает WPF, и вы подумываете о том, чтобы ваша команда перешла на WPF, то почему бы не использовать Silverlight? Вы получаете множество преимуществ WPF, но при этом сохраняете возможность оставить свой проект в виде веб-приложения. Поскольку вы рассматриваете большой модульный проект, имеет смысл использовать PRISM с WPF или Silverlight, чтобы упростить MVVM.
Моя команда недавно сделала выбор использовать Silverlight вместо asp.net. Это был фантастический выбор для нас. Изначально у нас был только один разработчик, который знал какой-либо Silverlight. Затем мы все прошли недельный тренировочный класс, который был в основном бесполезным, но по крайней мере намокли ноги. В итоге нам пришлось нанять двух подрядчиков, чтобы помочь нам в создании основной части нашей инфраструктуры пользовательского интерфейса. Большинство нашей команды до сих пор не уверены в своих навыках Silverlight. Я, первоначальный член команды со знанием Silverlight, и два подрядчика - те, кто делает основную часть разработки SL. После этого у нас есть два преданных участника. Я бы сказал, что нам потребовалось около 2 месяцев после принятия решения о переходе на Silverlight, чтобы мы действительно собрали что-то конкретное. Тем не мение, теперь у нас есть замечательный продукт, который очень напоминает клиентское приложение, которое работает внутри веб-браузера и не устанавливается ни на одном компьютере локально. Разработка длилась менее года, и мы почти готовы к выпуску или первому релизу кандидата.
Некоторые вещи для рассмотрения:
WPF или silverlight, в зависимости от того, что вы выберете, у ваших разработчиков будет немало знаний.
Silverlight может работать из браузера, если это необходимо. Если вы сделаете это, то довольно легко настроить его так, что если вы когда-нибудь развернете новую версию, то установленная из браузера SL программа автоматически обновится.
Silverlight не включает в себя все элементы управления, которые есть в WPF.
Последнее замечание: если вы хотите набрать код как можно быстрее, то очевидно, что вам следует использовать ASP.NET. Моя главная проблема с ASP заключается в том, что, если вы не дисциплинируете свою команду, проект ASP.NET будет легко загроможден и запутан. Если вы думаете, что сможете справиться с первоначальными затратами на освоение технологий, Silverlight или WPF предоставят вам множество замечательных возможностей.
источник
Эта часть довольно касается:
WPF не подходит для соединений с удаленным рабочим столом и тонким клиентом. Анимации не будут плавными, и любые сложные изображения (даже градиенты) замедляют отклик пользовательского интерфейса до сканирования. Административный персонал с типичными ретро-машинами XP также, скорее всего, будет иметь проблемы с производительностью сложных приложений WPF (из-за небольшого количества оперативной памяти и плохих графических процессоров).
Если вы идете по пути WPF для богатой графики, будьте готовы к последним хакам производительности, когда вы обнаружите, что целевым машинам десять лет. Придерживайтесь статичных экранов и используйте .NET 4.0, так как производительность WPF значительно улучшилась с 3.5.
источник
Технически я считаю, что комбинация WPF / WCF - лучшее решение.
Однако я не уверен, что ваш нынешний программист WPF действительно имеет опыт для этого проекта. WPF - это довольно серьезный сдвиг в программировании мыслительных процессов по сравнению с программированием в Winform, поэтому вам нужно будет долго и усердно задумываться о том, действительно ли у вас в команде достаточно навыков для реализации этого пути.
источник
Интересный. Это звучит поразительно знакомо приложению, которое мы только что запустили в моей компании (интеграция sip-телефонов и сканеров и все такое ).
Мы выбрали silverlight с акцентом на SOA, чтобы впоследствии можно было создать приложение WPF, если возникнет такая необходимость.
Мы используем MEF на уровне сервиса и строим точки расширения (интерфейсы плагинов, описывающие определенные точки, в которых мы планируем расширение или интеграцию с другими системами)
Не проблема.
Какого рода производительность? Воспринимаемая производительность (быстрота) или производительность хруста? Последнее может быть проблемой с приложением web / silverlight. В первом случае наше приложение просматривает множество записей, таких как ваша, но мы можем прогнозировать их и предварительно извлекать записи, пока пользователи работают над текущими. Время загрузки для этого раздела нашего приложения равно нулю.
Зависит от навыков. Но на самом деле каждый всегда хочет попасть на рынок как можно быстрее, так что это не аргумент.
Как и скорость производства, это также не аргумент, и он будет сводиться к методам проектирования и кодирования. Если вы говорите о техническом обслуживании оборудования, вы можете использовать облачное приложение.
Я не уверен, что это значит.
Silverlight 4 теперь предоставляет доступ к веб-камере / микрофону (мы надеемся провести видеоконференцсвязь между приложениями, а также интеграцию sip), поэтому, если вы используете телефонный сервер, вы можете написать его самостоятельно. Я не знаю ни одного из существующих, но это могло бы помочь.
В противном случае вам, возможно, придется сделать некрасивый хакер (извините, больше нет ссылки на статью / статьи), или у вас нет другого выбора, кроме как иметь приложение WPF, которое может взаимодействовать с файловой системой. SL4 может выйти из браузера, но он может получить доступ только к определенным частям файловой системы. Скорее всего, ни одна из них не станет той частью, которая необходима для взаимодействия с SIP-телефоном.
Вы имеете в виду, сканер документов? Я не уверен в этом. Мы используем ручные сканеры / сканеры штрих-кода, и они работают так же, как любое другое устройство ввода, и не являются проблемой.
источник
вам нужно очень отзывчивое приложение для людей, чтобы использовать весь день? использовать WPF; вам будет проще использовать компоненты GUI в WPF поверх ASP / MVC (IMHO)
да, jquery и др. великолепны, silverlight - это круто, но настольные приложения все еще более эффективны
для бэк-энда отлично подходит WCF
источник
Мне придется рекомендовать вам использовать WCF для уровня обслуживания из-за масштабируемости и безопасности. Для уровня презентации вы можете использовать либо Silverlight, либо ASP.NET, Silverlight похож на Flash, но поначалу это трудно понять и он имеет высокую кривую обучения, в основном при работе с данными. ASP.NET проще в использовании, но вам потребуется много настроек и JavaScript для его эффективного использования.
источник