Сложный вопрос по WPF, Win32, MFC

Question

Предположим, вы являетесь студентом по ИТ с базовыми знаниями C ++ и C #.Предположим, вы хотите разработать приложения, которые:

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

и вы хотите изучить API, который позволит вам писать приложения, подобные описанным ранее, и:

1. является основной
2. - будущееДоказательство
3. дает вам право найти достойную работу
4. достаточно просто - я имею в виду просто, как VCL, а не просто, как winapi

Итак, делая эти предположения, чтоApi вы выберете?MFC, WPF, другие?Мне действительно нравятся VCL и QT, но они не являются мейнстримом, и я думаю, что немногие работодатели захотят, чтобы вы писали приложения в QT или Visual C ++ Builder ...

Спасибо за ответы.

Answer 1

Примечание: Следующий ответ был написан несколько лет назад с учетом разработки приложений для настольных ПК. Сегодня (в 2018 году) вы, вероятно, просто создадите веб-приложение, чтобы в итоге получить что-то достаточно кроссплатформенное и независимое от устройства. (Например, использование ASP.NET Core на стороне сервера в сочетании с инфраструктурой / библиотекой пользовательского интерфейса, например React, Vue.js или Angular на стороне клиента).

• Win32 API - я бы забыл об этом, если бы я был вами. Программирование приложений Windows напрямую через Win32 API имеет смысл, только если вы программируете на чистом C, или вам действительно нужно выполнять много системных вызовов, или если вы беспокоитесь о дополнительных издержках, вызванных более «удобным» платформы или фреймворки (такие как названные ниже). Программирование пользовательского интерфейса непосредственно через Win32 API является утомительным, грязным, и вам нужно разобраться со множеством деталей. Он также не зависит от платформы, но вы можете или не можете быть обеспокоены этим.

• MFC - Возможно, вариант, если вы программируете на C ++ и исправлены на платформе Windows. Я никогда не понимал, что в этом такого хорошего, кроме того, что он делает API-интерфейс Win32 намного более удобным (AFAIK - это, в основном, коллекция объектно-ориентированных оболочек вокруг Win32 API, которые устраняют его сложность / запутанность). Кроме того, он также не очень независим от платформы.

• Qt , wxWidgets - довольно распространенные фреймворки пользовательского интерфейса. Могут быть хорошими вариантами, где независимость платформы играет роль. 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 Framework и WPF для пользовательского интерфейса, , если , вы планируете оставаться в основном в мире Microsoft. Помните, что вы все равно можете использовать Win32 API (вы не приблизитесь к "системным вызовам") ​​через P / Invoke.

Answer 2

Если вам нравится кодировать в C # и работать с .Net framework, я бы порекомендовал вам взглянуть на WPF. WPF - это отличный графический интерфейс, в котором вы можете делать практически все, а также делать его блестящим! WinForms может быть легче понять, но я бы сказал, что WPF более «перспективен на будущее». Еще один положительный момент заключается в том, что WPF действительно похож на Silverlight , поэтому, если вы хорошо справляетесь с WPF, вы также сможете писать приложения Silverlight - если это интересно. Пожалуйста, не пытайтесь изучать MFC ... Я не могу поверить, что многие используют MFC сегодня по другим причинам, чем то, что они использовали его раньше, и не получили возможности измениться.

Есть много хороших заданий для программистов .Net, поэтому возможность обрабатывать некоторые GUI-структуры в дополнение к C # и общие знания о .Net-инфраструктуре будут иметь смысл.

Когда речь заходит о том, что вы способны "обеспечить некоторую производительность, такую ​​как архиваторы, криптографические алгоритмы, кодеки", это действительно не должно зависеть от вашего выбора среды графического интерфейса. Этот вид кода будет записан в слоях вне уровня GUI и обычно будет привязан к GUI. С WPF вы напишите, например, свой. криптографические алгоритмы в C # в каком-либо классе, независимом от уровня GUI, и тогда представление, написанное в WPF, будет связываться с кодом C # и получать ответ отсюда. Однако если вы используете WinForms, вы все равно будете делать то же самое, и производительность зависит от алгоритмов, а не от GUI.

Когда дело доходит до начала работы с WPF, есть много вопросов о том, как SO помогает с этим. Таким образом, вы должны найти хорошую помощь с быстрым поиском.

Удачи!