Есть ли еще случай для MFC

МФЦ был хорошим вариантом 10 лет назад. Это по-прежнему хорошая оболочка над Win32 API, но, к сожалению, она устарела.

Qt - лучший вариант с одним большим преимуществом - он не зависит от платформы. С MFC вы обречены на Windows.

Я до сих пор использую MFC для всех приложений. MFC получил плохую репутацию из-за его ранних реализаций, но сейчас он превосходен. Я также считаю, что это немного удобнее, чем WTL. Кроме того, инструменты графического интерфейса в Visual Studio уже настроены, чтобы упростить быструю разработку графических интерфейсов с помощью MFC, сопоставления элементов управления с переменными, DDX и т. Д.

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

Преимущество MFC в том, что он по-прежнему лучше, чем кодирование под Win32, и вы можете распространять собственный .exe, который не требует времени выполнения 23-50 МБ, например .Net.

Теперь, если вас беспокоят эти вещи, существуют лучшие альтернативы: C ++ Builder, WxWidgets и т. Д. Но в некоторых местах не будут рассматриваться инструменты сторонних разработчиков.

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

Если вы собираетесь разработать настольное приложение для Windows только на C ++, то MFC - наиболее зрелый выбор, с большим количеством бесплатного кода на основе MFC в Интернете и большим количеством знаний.

Помимо Win32 api, MFC - единственная распространенная технология программирования для Windows, которая все еще жива и здорова в 2011 году после 15 с лишним лет. Еще в 2001 году все говорили: «MFC мертв, теперь все Winforms»; в 2005 году все говорили: «MFC мертв, теперь все в XAML»; сейчас 2011 год, и Winforms и XAML мертвы (хорошо, XAML, возможно, не совсем мертв, но уже давно прошел), а MFC все еще обновляется последними разработками (лента, расширения Aero, API Win7 и т. д.).

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

(то же самое и для C ++, кстати)

Вот возможность - представьте себе приложение, которому потребуется большой объем памяти, например, графическая программа, игра или, может быть, какое-нибудь высокопроизводительное бизнес-приложение. Ни для кого не секрет, что приложения .NET занимают много памяти - в таком случае вам может потребоваться экономичное приложение MFC для ядра вашего приложения. Вы всегда можете загрузить и использовать компоненты .NET, элементы управления и т. Д. Через вызываемые COM-оболочки или напрямую через C ++ / CLI.

При этом MFC - это боль. Вместо этого рассмотрите WTL - вы все равно можете вызывать .NET, если вам нужно, так же, как я упоминал выше для MFC. WTL намного лучше, чем MFC :-)

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

Я думаю, что нет .. MFC проиграет в

• Уровень абстракции
• Время разработки
• Время устранения неполадок
• Кривая обучения для новых разработчиков
• Перспективы (хотя сейчас это сомнительно ... каждые 3-4 года появляется что-то новое)
• Поиск хороших людей, знающих свой МФЦ
• Простые в использовании элементы управления

Единственное место, где MFC, вероятно, проскользнет мимо, - это если у вас есть приложения с очень высокой производительностью, например, у вас есть вещи на экране, которые необходимо перерисовывать каждые 10 мс или 1 секунду. «Управляемые» приложения до сих пор не смогли преодолеть это препятствие.

MFC был важным шагом в эволюции, но теперь доступны лучшие варианты.

Краткий обзор нового Функциональность MFC

Я слышал, у них есть новый элемент управления лентой. Если вам нравятся такие сложности. Вот скриншот недавно созданного приложения:

_{(источник: msdn.com)}

На самом деле это просто обновление виджета. Так нужно ли нам больше виджетов?

Существующий Windows API полностью основан на C. Если вы хотите использовать C ++ (а вам, вероятно, следует), то MFC - это логичный выбор, если вы хотите оставаться нативным (то есть не использовать .NET).

MFC - это просто набор объектно-ориентированных классов поверх C API. Плюс немало дополнительных «вспомогательных» классов, облегчающих выполнение повседневных задач.

Только по дизайну и техническим характеристикам? Извините за категоричность, но нет. Это плохой дизайн, очень дырявая абстракция, в которой вам приходится возвращаться к программированию Win32 API, вопиющим образом злоупотреблять C ++ и твердо нацелено на вчерашние технологии: вы не получите современного (или даже привлекательного!) Взаимодействия с пользователем. приложение MFC. Если у вас есть разработчики C # и у вас нет серьезных аппаратных ограничений, используйте WinForms.

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

Если вы разрабатываете Windows CE и мобильные приложения на C ++, как уже упоминал Эйнар, MFC - хороший выбор. Если вы сделаете этот выбор, MFC также станет разумным выбором для настольного компьютера, поскольку вы можете использовать один и тот же код для настольных и портативных устройств. MFC остается хорошей производительностью / легко реализуемой комбинацией в этом сценарии. Лично я использую MFC вместе с библиотеками Stingray в этих средах, что дает очень хороший интерфейс, хорошую производительность, а также быстрое и простое внедрение.

Я бы сказал, что скорость и занимаемая площадь - веские причины по сравнению с .NET.

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

Я писал кросс-платформенный код в течение многих лет, поэтому, когда мне нужно что-то написать, у меня всегда есть очень тонкий слой абстракции между ним и системными вызовами почти для всего, кроме вызовов posix. Таким образом, вы можете запрограммировать его в MFC, но при необходимости довольно легко преобразовать его в другой API позже. Мой базовый набор библиотек C ++, которые я использую для всего, делает это с помощью небольшого класса System. В настоящее время я использую MFC для Windows, а также использую XWindows для Linux и собственную версию для Mac. А потом, когда я портирую его на КПК, это должно быть безболезненно.

Если вы хотите взглянуть, это LGPL и находится по адресу:

http://code.google.com/p/kgui/