Сложный вопрос на WPF, Win32, MFC
Давайте предположим, что Вы - студент IT с элементарными знаниями C++ и C#. Давайте предположим, что Вы хотите разработать приложения что:
- потребность обеспечить некоторую производительность как archivers, криптографические алгоритмы, кодеки
- используйте некоторые системные вызовы
- имейте gui
и Вы хотите изучить API, который позволит Вам записать приложения как описанные ранее и:
- господствующая тенденция
- соответствует требованиям завтрашнего дня
- дает право Вам находить достойное задание
- достаточно легко - я имею в виду легкий как VCL, не легкий как winapi
Так, делая эти предположения, какой API Вы выберете? MFC, WPF, другой? Мне действительно нравятся VCL и QT, но они не господствующая тенденция, и я думаю, что немного работодателей захотят, чтобы Вы записали приложения в Разработчике спокойного или Visual C++...
Спасибо за ответы.
2 ответа
Примечание: Следующий ответ был написан несколько лет назад, имея в виду разработку настольных приложений. Сегодня (в 2018 году) вы, вероятно, просто создадите веб-приложение, чтобы получить что-то достаточно кроссплатформенное и независимое от устройств. (Например, с использованием ASP.NET Core на стороне сервера в сочетании с инфраструктурой / библиотекой пользовательского интерфейса, такой как React, Vue.js или Angular на стороне клиента).
Win32 API - на вашем месте я бы об этом забыл. Программирование приложения Windows напрямую через Win32 API имеет смысл только в том случае, если вы программируете на чистом C, или если вам действительно нужно выполнять много системных вызовов, или если вас беспокоят дополнительные накладные расходы, связанные с более "удобными" платформы или фреймворки (например, указанные ниже). Программирование пользовательского интерфейса напрямую через Win32 API утомительно, беспорядочно, и вам нужно разобраться с множеством деталей. Это также совершенно не зависит от платформы, но вы можете или не беспокоиться об этом.
MFC - Возможно, вариант, если вы программируете на C ++ и исправили на платформе Windows. Я никогда не понимал, что в нем такого замечательного, кроме того, что он делает Win32 API намного более удобным (AFAIK, по сути, это набор объектно-ориентированных оболочек вокруг Win32 API, которые убирают часть его сложности / беспорядка). Кроме того, он не очень независим от платформы.
Qt , wxWidgets - Достаточно распространенные UI-фреймворки. Могут быть хорошими вариантами, когда независимость от платформы играет роль. AFAIK, обе структуры ориентированы на язык C ++.
WinForms (.NET) - Подобно MFC, он также основан на Win32 API (USER32 и GDI +). AFAIK, фреймворк WinForms теперь переносится на Mono и, следовательно, в некоторой степени кроссплатформенный. Однако это не самая современная технология. Для сложных пользовательских интерфейсов иногда это может быть несколько вялым. Если бы мне пришлось решать сегодня, какую структуру использовать, я бы предпочел ...:
WPF (.NET) - Более современный, чем WinForms, с большими графическими возможностями и, очевидно, более быстрым рендерингом, поскольку он больше не основан на Win32 API (GDI). (И он работает на .NET, который я считаю отличной платформой для разработки. Программирование на C # намного проще, чем программирование на C ++ IMHO, что также является аргументом против Win32 API, MFC, Qt и wxWidgets.) Обратите внимание, что WPF не является кроссплатформенным, пока он существует только на платформе Windows.
И, конечно же, есть Java , включая фреймворки пользовательского интерфейса, которые идут вместе с ним. Я не могу много говорить об этом, поскольку я не являюсь специалистом по Java, но я мог представить, что Java будет лучшим выбором для независимости от платформы; и это доминирующая платформа (над .NET) в определенных отраслях (например, мобильные телефоны, банковское дело, из-за очень надежной JVM и соображений безопасности).
Итак, я рекомендую использовать платформу .NET и WPF для пользовательского интерфейса, если вы планируете оставаться в основном в мире Microsoft.Помните, что вы все еще можете использовать Win32 API (вы не приблизитесь к «системным вызовам», чем это) через P / Invoke.
Если вам нравится кодировать на C # и работать с инфраструктурой .Net, я бы порекомендовал вам взглянуть на WPF. WPF - отличная среда графического интерфейса, в которой вы можете делать что угодно - и при этом сиять! WinForms может быть проще для понимания, но я бы сказал, что WPF является более «перспективным». Еще одним положительным моментом является то, что WPF действительно похож на Silverlight , поэтому, если вы хорошо справляетесь с WPF, вы также сможете писать приложения Silverlight - если это интересно. Пожалуйста, не утруждайте себя изучением MFC .. Я не могу поверить, что многие люди используют MFC сегодня по другим причинам, кроме тех, которые они использовали раньше, и не получили возможности что-то изменить ..
Есть много хороших рабочих мест для программистов .Net, так что возможность обрабатывать некоторую среду графического интерфейса в дополнение к C # и общие знания о среде .Net будет стоить того.
Когда дело доходит до ваших замечаний о возможности «обеспечить некоторую производительность, например, архиваторы, криптографические алгоритмы, кодеки», это не должно зависеть от вашего выбора среды графического интерфейса пользователя. Этот вид кода будет написан на уровнях за пределами уровня графического интерфейса пользователя и обычно будет привязан к графическому интерфейсу. С WPF вы должны написать, например, криптографические алгоритмы в C # в некотором классе, не зависящем от уровня графического интерфейса пользователя, а затем представление, написанное в WPF, будет связываться с кодом C # и получать свой ответ отсюда. Однако, если бы вы использовали WinForms, вы все равно делали бы то же самое, а производительность зависит от алгоритмов, а не от графического интерфейса.
Когда дело доходит до начала работы с WPF, возникает множество вопросов о том, как SO помогает с этим. Так что вы должны найти хорошую помощь с быстрым поиском.
Удачи!