.NET или Mono vs Qt, какой для кросс-платформенной разработки?

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

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

Вот некоторые связанные вопросы по теме:

Изменить: Использует ли Mono только жизнеспособный вариант, если Windows является одной из целевых платформ?

Ответ 1

Вы выбрали Mono (и, возможно, С#) для кросс-платформенной разработки по той же причине, что кто-то выбрал Java или Python. Эти языки работают на виртуальной машине, и если вы тщательно выбираете библиотеки и разрабатываете код, он будет работать с перекрестной платформой (без перекомпиляции). У родных языков (например, C, С++) есть стандарты, поэтому язык на разных платформах одинаковый, но параметры и используемые вами параметры компилятора могут быть не перекрестной (например, процессы, сети и т.д.).

Помимо технических проблем, знакомство кросс-платформенной платформы экономит время. Например. изучение библиотеки GUI может занять недели/месяцы. Очевидно, вы сэкономите время, если API будет одинаковым для всех целей.

Qt4 хорошо спроектирован, хорошо документирован и поставляется с некоторыми полезными, прочными инструментами. wxWidgets становится массивным с десятками виджетов, некоторые из которых вы никогда не будете использовать. У Qt меньше виджета, которые более гибкие. Я использовал wx довольно много, но теперь я конвертирую Qt из-за лицензии LGPL, хороших документов, дизайнера, PyQt, новой среды разработки и растущей базы пользователей.

Оба Qt и wxWidgets имеют привязки Python (т.е. PyQt и wxPython), поэтому вы можете писать кросс-платформенный GUI-код, используя эти библиотеки. Для Mono это более сложно, но есть GTK # и Qyoto. Я не пробовал ни одного из них, но они, похоже, доходят до точки, где они достаточно зрелы, чтобы их использовать (например, см. MonoDevelop).

Ответ 2

Для кросс-платформенной (и уникальной платформы) я бы пошел в Qt, потому что он был более чистым, чем Mono и Windows.Forms, а с шаблоном MVC все приложение проще расширять и изменять

Ответ 3

Я использую Qt4 для кросс-платформенной разработки и очень доволен этим. Развертывание работает нормально (по крайней мере, если вы ставите Qt статически, что совсем не сложно), API действительно приятный и последовательный, и Qt Designer позволяет быстро развить части GUI, чтобы можно было сосредоточиться на реальной логике. Концепция сигнала и слота также мне очень нравится, когда вы привыкли к ней.

Из моего опыта развертывание с развертыванием wxWidgets сложнее (в моем случае это был именно Linux из-за зависимости от GTK, не знаю о Mac).

Ответ 4

Возможно, вы можете написать большую часть приложения на переносимом языке/фреймворке и написать отдельный "интерфейс графического интерфейса" для каждой операционной системы, которую вы планируете поддерживать? Эта стратегия, конечно, может хорошо работать в некоторых случаях, но может быть неудачной и ужасно у многих других.

Ответ 5

Вот еще один вариант, о котором вы не упоминаете, и я не заметил упоминания здесь, но Lazarus является кроссплатформенным и становясь более зрелым, когда он движется вперед. Конечно, как что-то, написанное в Qt, вам придется скомпилировать его для определенных платформ. В моем случае я успешно использовал Lazarus в проекте, который работает на Mac OSX, Linux и Windows. Lazarus - хороший инструмент RAD, а Object Pascal хорошо работает для большинства вещей, которые я написал. Lazarus - хороший вариант для скорости приложения. Он хорошо сравнивается с программным обеспечением, написанным на c/С++. Я не собираюсь это делать, есть примеры из практики, и вы можете сделать свое собственное тестирование, если вам нужно.

Мое впечатление от кодирования в С#, использующем MonoDevelop, было то, что библиотека-мудрый, в частности html и аудио немного сложнее. Я играю только с С#/MonoDevelop в течение нескольких месяцев, поэтому я все еще совершенно новый со всем комплектом. Я бы предположил, что есть небольшая цена за скорость, так как это управляемый код. Опять же, я думаю, что исследования предполагают, что скомпилированный код будет чаще, чем не иметь преимущество по скорости над кодом С#/. NET.

Конечно, другим вариантом будет Java. Я не делал так много, но это, безусловно, уродливо и хорошо работает, я бы ожидал, что код Java будет медленнее, чем только скомпилированный код, такой как c/С++/Pascal.

Еще один вариант, который приходит на ум, у которого есть компиляторы для трех основных платформ, Eiffel. В наши дни я не очень много делаю, но мне понравилось, когда я играл с ним. YMMV

Ответ 6

Вы рассматривали wxWidgets. Его также кросс-платформенный, С++, как QT, и использует собственные элементы управления, в отличие от QT, и не требует каких-либо фреймворков для запуска, как .NET.

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

Если производительность является критическим аспектом приложения, многие люди используют библиотеки С++, такие как QT, wxWidgets.

Ответ 7

.NET не для кросс-платформы. Очень сложно кодировать и эффективно работать для MONO и .NET. Причина, по которой люди идут с .NET больше, чем TCL/Tk или Qt или Java Swing из-за быстрой разработки приложений.

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

Инструментарий GUI в целом трудно работать, потому что вам нужно понять основы. Основами являются привязка данных, обрезка, обновление, управление макетами и обработка событий. Для этих разработчиков сложные разработчики сложны. Причина в том, что большая часть его отвлекается на большее количество современных инструментов. Например, с Java Swing мне не нужно ничего знать об обрезании или освежении, так как они делают это "магически" для меня. Что происходит в случае, когда что-то не освежает волшебно, эта ситуация тогда представляет практически невозможное решение. Затем код становится экспоненциально более сложным.

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