Какие факторы следует учитывать при выборе среды выполнения / языка для настольных приложений Windows?

10

У всех моих пользователей Windows. Некоторые из них используют Linux или Mac, но если они это делают, они обычно могут использовать что-то вроде Mono, Wine, Parallels или двойной загрузки.

Моя команда разработчиков (включая меня) имеет большой опыт написания приложений Swing на Java, а также Windows Forms на C #. «Обширный» означает, что мы разработали и поставили более трех приложений в обе среды выполнения. Эти приложения являются приложениями технического анализа, поэтому они слабо взаимодействуют с базой данных, но сильно зависят от пользовательского интерфейса и размеров наборов данных.

Мы подошли к тому моменту, когда мы действительно хотим принять решение о том, на какой платформе сосредоточиться с этого момента, так как это становится бременем для поддержки обоих (если вы работаете в Swing в течение полугода, это слишком много хлопот снова привыкнуть к Windows Forms и наоборот) и мы хотим, чтобы все в нашей команде могли работать над всеми нашими приложениями.

  • Windows Forms обычно требует меньше усилий для создания узнаваемых приложений Windows. Никакое количество скинов и пользовательских элементов управления в Java не решило это за эти годы. В то же время у нас никогда не было клиента, который не мог бы использовать приложения Swing.
  • Раньше Java имела гораздо более богатую экосистему с точки зрения библиотек и инструментов автоматизированной сборки, но это быстро меняется (Java не падает, тем более что .NET догоняет).
  • В редких случаях, когда мультиплатформенность предпочтительнее, Java опережает .NET. Mono - это замечательно, но это все же больше работы, чем Java.

Если мы выбираем .NET, мы можем сосредоточиться на WPF, но также начать использовать F #. Если мы выберем Java, мы можем сосредоточиться на RCP, но также начать использовать Scala.

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

(Обратите внимание: на Programmers.SE уже есть похожие вопросы, но они либо неконструктивны, либо под другим углом.)

Декард
источник
2
Исходя из сути прочитанного, я считаю, что заголовок вопроса должен звучать так: «Какие факторы следует учитывать при выборе среды выполнения / языка для настольного приложения Windows?» , уделяя больше внимания аспекту принятия решения вашего вопроса. На этот вопрос ответить гораздо проще и менее заразительно, чем «Что мне следует использовать?» - вопрос такого рода, как представляется из названия.
Спойк
@ Спайк Замечательно, я обновил заголовок (сделал его немного короче).
Deckard
1
Может быть, по этой ссылке есть кое-что о будущем Windows, что очень важно для вас, ребята. IMHO- zdnet.com/blog/microsoft/…
Гульшан
Заставить пользователей Mac установить Wine и запустить приложение для Windows - все равно что пытать их.
вправо

Ответы:

7

Мы пошли на Java (Swing) плюс некоторые нативные части через JNI. В то время как коммерческий спрос на мультиплатформенность сегодня может быть незначительным, ситуация может измениться через 5 лет, и жизненный цикл приложения (приложения для научных измерений) будет более 10 лет (его предшественник C ++, все еще используемый сегодня, имеет исходные файлы от 1991 года). Как вы писали, Java опережает .NET в средах, отличных от Windows, и если нам когда-либо понадобится переключиться с Windows, это просто вопрос перекомпиляции некоторых нативных частей, возможно, тонкой настройки внешнего вида графического интерфейса и проверки того, что все работает.

Если вы уверены, что будете использовать только Windows, а ваше приложение будет работать всего несколько лет, тогда предпочтение может отдаться .NET - оно выглядит и ведет себя больше как собственное приложение, потому что оно есть. Но в качестве долгосрочной инвестиции я больше доверяю Java. Swing может выглядеть немного не идеально, время запуска может быть больше, все немного неоптимально из-за многоплатформенного уровня абстракции, но, по крайней мере, он «просто работает».

Joonas Pulakka
источник
2
Чем приложение .NET является более родным приложением Windows, чем Java?
Рей Миясака
@Rei: в этом .NET Framework доступна только для Windows. Конечно, есть моно, но он всегда отстает, и в настоящее время его будущее, ну, в общем, неопределенно.
Тамас Селеи
1
@ Тамас Это совершенно другой случайный вопрос. Помимо нескольких первых байтов кода в .exes, которые печатают «Эта программа не может быть запущена в режиме DOS», программа все еще является полностью байтовым кодом. Библиотека Java так же родна для Windows, как и библиотека .NET, даже если обратное может быть неверным из-за отсутствия реализации.
Рей Миясака
4

Вещь, которую вы можете рассмотреть, - это проект IKVM, позволяющий использовать код Java в мире .NET. Затем вы можете воспользоваться преимуществами Java-бэкенда, в то время как, насколько я понимаю, у вас может быть тонкий передний слой в Swing или WinForms.

http://www.ikvm.net/

Я слышал, что другие использовали это, чтобы использовать библиотеку соединений с открытым исходным кодом, написанную на Java из .NET, вместо того, чтобы использовать громоздкую версию .NET.


источник
3

На MSDN есть ресурс, который может быть вам полезен: http://msdn.microsoft.com/en-us/gg715299.aspx .

Если вы перейдете к нижней части страницы, вы найдете множество технических документов, которые концептуально сравнивают Java и .NET. Конечно, поскольку он находится на MSDN, он смещен в сторону .NET, но ресурсы все еще весьма полезны.

Дэвид Саламон
источник
1

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

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

Есть моменты, когда лучше иметь 2 базовых кода. Если, например, написание вашего приложения в WPF элегантно для .NET, а написание, скажем, в Cocoa - элегантно для Mac OS, результирующий код может быть на самом деле меньше, чем, скажем, с использованием Java или Mono (который не имеет WPF). В этом случае вы можете получить лучшие результаты с меньшим количеством кода.

Последнее соображение, возможно, заключается в том, чтобы сделать ваше приложение приложением HTML5 или даже расширением Chrome, но это может быть слишком левое поле.

Кевин Хсу
источник
1

Вы рассматривали Silverlight ? Это может быть хорошим выбором для сборки приложений Windows Desktop (от SL4 +) и отлично работает на Mac.

ADIMO
источник
SL почти мертв ..
klm_
Microsoft так не считает. Лично я считаю, что html5 - лучший выбор для веб-приложений, но SL на стороне клиента может быть хорошей технологией.
ADIMO
Я также хотел бы перейти на HTML5, потому что он поддерживается W3O. Silverlight конкурирует с HTML5 и, если он не займет нишу, он умрет, я думаю.
klm_
1

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

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

  • Интеграция с COM - это боль, а COM + иногда невозможен (потраченные впустую недели на то, чтобы заставить его работать с Windows Tablet API).
  • Аппаратное взаимодействие может повредить. Иногда API доступен только на одной платформе (например, интеграция камеры / сканера).
  • Взаимодействие с локальными приложениями тоже может повредить. Я упоминал, что боль COM? Ну, другой способ (который мы фактически использовали) состоял в том, чтобы сгенерировать и выполнить сценарии VBS, которые запускают приложение Windows, такое как MapPoint, или какое-то проприетарное приложение отображения, и загружают его данными.
  • Интеграция и интеграция с рабочим столом (ярлыки, деинсталлятор, меню «Пуск») также могут повредить. Веб-старт очень ненадежен. Альтернативы либо стоят дорого, либо отсутствуют некоторые функции (например, распространение обновлений).

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

Конрад Гарус
источник