Какой язык/платформа разработать настольное приложение на основе следующих [закрытых] критериев

Ваш XML-файл использует нестандартное пространство имен rdf, но не определяет его. Вам необходимо определить пространство имен в XML:


Некоторые анализаторы XML позволяют объявлять пространства имен в вашем коде вне документа XML, но я не нашел ничего подобного после быстрого просмотра в sxd_document документах .

6
задан Prembo 22 January 2009 в 01:27
поделиться

8 ответов

Честно говоря, я выбрал бы Java (с маленьким компонентом C) по следующим причинам, на основе Ваших требований.

  • Lifetime of language/API/platform/framework- i.e., how future-proof will the investment in this application be?... the product has a long life-cycle (10). Это действительно зависит от того, под чем Вы подразумеваете долго. Я серьезно не могу вообразить исчезновение Java, просто из-за его огромной установленной основы. C или C++ не исчезает ни один, но я всегда думаю о проблемах миграции VB6-to-VB.net при рассмотрении будущего C#.

  • Will need to communicate with devices using USB and/or ethernet (9). Пока Java не непосредственно идеален для этого, он имеет JNI, чтобы сделать трудную работу. Вам все еще будет нужен компонент C, чтобы сделать это (и он изменится для каждой платформы, но лучше иметь объем Вашего неперезаписываемого кода - с C, у Вас, вероятно, будет большая часть своего кода, изменяющегося для каждой платформы, и с C#, ну, в общем, это действительно поддерживаемый на платформах кроме Windows?). Другая альтернатива является JNA, который похож на a "Python ctypes" для Java (доступ к общим библиотекам и DLLs без слоя взаимодействия через интерфейс JNI).

  • Availability of resources, tutorials, support (9). Все языки имеют огромное поперечное сечение ресурса в сети.

  • Richness and breadth of libraries available (9). У Вас есть Повышение для C++ и межплатформенных графический интерфейсов пользователя, но они - что-то, что должно быть добавлено - нет ничего, встроил к среде разработки как с Eclipse/Java.

  • Unit testing (9). Тот же ответ как доступность инструментов ниже - существует много (свободных) плагинов Eclipse, которые автоматизируют поблочное тестирование.

  • Availability of engineers with relevant skills (8). Все языки, которые Вы упоминаете, имеют изобилие (я люблю использовать то слово) людей, которые в состоянии сделать задание.

  • Availability of quality IDE/tools (8). Это - Eclipse. Никакие два пути об этом, в моем уме. Количество плагинов для него действительно огромное. NetBeans может выглядеть более хорошим, но у меня были бы функциональность, чем взгляды (и так был бы моя жена, таким образом, это удачно :-).

  • Cost of IDE/tools (7). Eclipse свободен.

  • The application will need to be able to interpret a scripting language (6). В последний раз я слышал, Java теперь включает JavaScript как встроенное, а также способность к разработчикам добавить их собственные механизмы выполнения сценариев.

  • Cross-platform (3). C#, нет (несмотря на существование Моно, я все еще вижу риски, что это столкнется с MS однажды, и что не многие - мир FOSS, будет работать над ним из-за его ассоциаций MS).

11
ответ дан 8 December 2019 в 02:12
поделиться

Я пойду с C# для этого по нескольким причинам:

  • Самый близкий относительно C++ с точки зрения синтаксиса;
  • Прямой доступ к памяти при необходимости с unsafe блоки;
  • Современный UI с более низкой ценой разработки, чем какая-либо платформа UI C++;
  • Высокая доступность навыков;
  • Благодаря Microsoft и другим, библиотекам для примерно чего-либо (включая USB);
  • Visual Studio является относительно дешевой;
  • Long ожидал время жизни: .NET является оба довольно сформировавшимся (в 7 + годы) и тот с лучшими долгосрочными перспективами "платформ байт-кода" (прежде всего, включая Java);
  • Простая интеграция собственного кода через DLLs. Java/JNI (говорящий на основе опыта) является просто настолько намного более неловким; и
  • Платформы поблочного тестирования.

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

Единственная вещь, в которой испытывает недостаток решение C#/.Net, является межплатформенной (Моно, несмотря на это). Я не знаю, сколько из грандиозного предприятия, которое является для Вас, но Вы только перечислили его как 3.

6
ответ дан 8 December 2019 в 02:12
поделиться

Моим предпочтительным вариантом был бы C++

  1. "Время жизни языка"... Я не думаю, что C/C++ идет куда угодно в ближайшее время.
  2. Поддержка низкоуровневой связи с usb/Ethernet/другими
  3. У Вас уже есть знание/набор навыков в Вашей команде
  4. Много библиотек/IDE хорошего качества, и т.д. доступных
11
ответ дан 8 December 2019 в 02:12
поделиться

Настольное приложение будет управлять устройством

C++

3
ответ дан 8 December 2019 в 02:12
поделиться

Лично, я выбрал бы C++ или C (или возможно даже D) для аппаратного интерфейса низкого уровня, но затем я оберну тот код в хорошем, чистом API, и я записал бы весь стоящий с пользователем материал GUI в C# с WPF и XAML.

Набор навыков потребовал в письменной форме, чтобы драйвер устройства полностью отличался от набора навыков разработчиков GUI (особенно, если Вы захотите предоставить богатые графические диаграммы и отчеты. Таким образом, Вы, вероятно, собираетесь иметь две различных команды во всяком случае (даже если они будут очень малочисленными командами), и реализация этих двух слоев в различном (но совместимый), то языки будут privide хороший механизм для осуществления разделения проблем между теми слоями.

4
ответ дан 8 December 2019 в 02:12
поделиться

Я вижу, что существует много людей C# здесь, - C#: не работает хорошо над другими платформами, чем Windows. Таким образом, это - плохая идея. Забудьте это. - Java: Не хороший для драйверов устройств, и еще медленнее, чем C или C++. Java имеет некоторые хорошие функции, но существует многим людям там, который думает путь к высоко об этом. - VB: Почему Вы хотели бы использовать это?

Я был бы probobly использовать C++ / QT, единственный недостаток состоит в том, что QT стоил денег, если это - коммерческий продукт, если это не это, свободно. Вы говорите, что у Вашей команды уже есть опыт C++, таким образом, чем он не должен быть к трудно, чтобы изучить, как использовать QT. И это будет работать и выглядеть очень хорошим и в Windows, Linux и в Mac. Язь не является проблемой с QT, Trolltech разрабатывают кросс-платформенного язя, которого Вы могли использовать, или Вы можете нас Visual Studio, eclips или другой язь C++.

3
ответ дан 8 December 2019 в 02:12
поделиться

Если бы я выпускал что-то прямо сейчас, то C++/wxWidgets без труда победил бы. Комбинация является очень портативной, а также удовлетворяющий всю Вашу доступность и проблемы стоимости.

В начале следующего месяца, если я помню правильно, QT будет выпущен в соответствии с лицензией LGPL. Я никогда не использовал его сам, но я услышал, что несколько человек поют его похвалы; лицензионные требования были единственной вещью, мешающей мне смотреть на него. Это, вероятно, было бы столь же хорошо как wxWidgets для Ваших потребностей.

Ни один из них не обрабатывает сценарии или поблочное тестирование, насколько я знаю.

Я посмотрел бы на использование Python как язык сценариев. Это имеет хорошую репутацию встроенного языка сценариев для других программ.

Я никогда не находил платформу поблочного тестирования, которую я люблю, таким образом, я не могу рекомендовать тот.

4
ответ дан 8 December 2019 в 02:12
поделиться

Я голосовал бы за C#. Даже с кривой обучения отодвигания от C++ Ваши разработчики должны быть более продуктивными и инструменты, и библиотеки являются большими.

Единственное место, которое я вижу, что C# добавляет к сложности Вашего проекта, будет взаимодействовать через интерфейс к Вашему USB-устройству, но довольно легко набрать скорость с P/Invoke и / C++ / CLI для представления драйвера C/C++.NET.

2
ответ дан 8 December 2019 в 02:12
поделиться