Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире
Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1
— я обещал товарищу MasterZiv вернуться к теме
обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).
Я начал заниматься на MFC в 1999 году. Точнее скажу, что это была первая освоенная мной библиотека классов.
После неё было: Borland C++ Builder (VCL); .NET (C#) и, наконец, Qt. Посему — вроде как есть с чем сравнить.
Впрочем — сравнивать C# и MFC как-то нелогично (разные базовые языки), поэтому оставим только то, что на C++
Попутно замечу, что для некоторых проектов я применяю MFC и на сегодняшний день.
ДОСТОИНСТВА:
1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
надстройка над WIN API, то она весит совсем не много. По современным меркам — практически ничего.
2) Интуитивная ясность библиотеки MFC для разработчиков, владеющих WIN API. Библиотека классов MFC представляет
набор классов и методов для тех сущностей, которые составляют основу оконного интерфейса Windows, что упрощает
понимание сущностей, определенных в библиотеке MFC.
3) Большой объем наработок — как в интернете (codeguru, codeproject и т.д.), так и в старых репозиториях разработчиков,
посему — возможность быстро получить ответ (в т.ч. и здесь — на КЫВТе) по самым различным аспектам применения.
4) За счёт простоты, благодаря наличию исходников и уже указанным наработкам — большая кастомизируемость
(возможность сделать то, что хочет левая пятка Заказчика).
5) Следует отметить, что MFC развивается (правда экстенсивно) — MFC Feature Pack позволает разрабатывать
приложения с довольно современным GUI. Тот факт, что в оставку MSVC2015 вернули MBCS — Multi Byte Character Set
(которую уже выбросили из MSVC2013) — также несомненно свидетельствует о некоторой популярности MFC в наши дни.
НЕДОСТАТКИ (как всегда — обратная сторона достоинств):
a) Достаточно простые на сегодняшний день вещи, оказывается сделать совсем не просто. Конечно, если работал с MFC
долгие годы, то выход найдёшь. Но это уже совсем другая история
Так, например, ComboBox в составе тулбара: в Qt несколько строк; на MFC — куча кода
Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt
имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы
выполнить совсем не сложный SQL запрос.
b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC. Программируя на MFC, разработчик
всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода.
Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями.
Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными
техническими сущностями.
c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном!
Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp)
оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками
переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться,
просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент).
В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!
d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.
Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую
тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах —
напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально.
Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++
Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса...
... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).
Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет
отступление от идей нормального объектно-ориентированного дизайна.
Я прекрасно понимаю, что есть требования совместимости со старым кодом, но ведь могли же ввести, наряду с поддержкой старого, и какие-либо
новые варианты — соответствующие сегодняшнему уровню развития технологий...
Или же M$ уже собралась хоронить MFC
Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость.
Нередко это просто диалоговое окно со статически прилинкованной библиотекой MFC.
Для более сложных проектов — очевиден выбор Qt.
Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.
Благодарю всех, у кого хватило терпения дочитать до этой строчки!
И еще более благодарю тех, кто выразит свои мысли по данному поводу!
Здравствуйте, sergey2b, Вы писали:
S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI
В своё время неплохой была книжка Д.Круглински. Piter Press издавало её на русском.
Сейчас может чего-то новое появилось.
За исключением версии Студии и "нового" Feature Pack книжка по-прежнему актуальна.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, AlexGin, Вы писали:
S>Дайте пожалуйста совет по какой ниги лучше изчучать MFC так как сейчас впервый разв в жизни стал использовать MFC для GUI
Раньше было немало книг по MFC. Перечислю некоторые, наиболее удачные, из них:
1) Круглински Д., Уингоу С., Шеферд Дж. — Программирование на Microsoft Visual C++ 6.0 для профессионалов
2) Jeff Prosise — Programming Windows with MFC, Second Edition (нет в русском переводе, я скачал англоязычную)
3) Кейт Грегори — Использование Visual C++ 6
Где найти сейчас эти книги — не знаю. Может удасться скачать где-либо.
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, sergey2b, Вы писали:
S>> сейчас впервый разв в жизни стал использовать MFC для GUI
bnk>Нелегко тебе однако. Йоханнесбург?
Здравствуйте, AlexGin, Вы писали:
AG>Раньше было немало книг по MFC. Перечислю некоторые, наиболее удачные, из них: AG>1) Круглински Д., Уингоу С., Шеферд Дж. — Программирование на Microsoft Visual C++ 6.0 для профессионалов AG>2) Jeff Prosise — Programming Windows with MFC, Second Edition (нет в русском переводе, я скачал англоязычную) AG>3) Кейт Грегори — Использование Visual C++ 6 AG>Где найти сейчас эти книги — не знаю. Может удасться скачать где-либо.
если не найдутся, у моего друга вроде как были, скину если надо будет
Здравствуйте, rumit7, Вы писали:
R>если не найдутся, у моего друга вроде как были, скину если надо будет
Спасибо, уважаемый rumit7, у меня всё по MFC есть
Это спрашивал sergey2b, у которого возникла необходимость в изучении MFC.
Здравствуйте, AlexGin, Вы писали:
AG>И еще более благодарю тех, кто выразит свои мысли по данному поводу!
К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.
Так же хорошая поддержка COM.
Ну и мне всегда нравился класс CSocket для простеньких сетевых приложений. Для сложных вещей конечно этот класс использовать не надо.
Здравствуйте, Evgeniy Skvortsov, Вы писали:
ES>К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.
+100500
Это, конечно несомненно так, студия много чего (в плане заготовок для новых приложений) умеет сделать сама.
Мне часто кажется, что M$ снабдила свою студию таким набором визардов для MFC, для того,
чтобы скрыть все непрстые особонности применения дянной библиотеки. Типа: "а у на это — прямо из коробки, и вот это, и вот то..." —
в общем некоторое решение, может даже неплохое, чтобы как-то компенсировать разбухание прикладного C++ кода.
ES>Так же хорошая поддержка COM.
Да, COM — хорошая штука, но на уровне современных решений это довольно сложная вещица.
На сегодняшний день востребованы более простые для прикладного применения решения.
Здравствуйте, AlexGin, Вы писали:
AG>Всё приведенное ниже, это лично мои соображения по самой библиотеке MFC и по поводу места данного продукта в современном мире AG>Кроме того, здесь: http://rsdn.org/forum/cpp.qt/6769008.1
— я обещал товарищу MasterZiv вернуться к теме AG>обсуждения MFC (только уже в данном разделе, а не в разделе по Qt).
Ну, тогда не могу не поучаствовать в топике
AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не
понимают. Для многих MFC -- это огромный и страшный монстр.
AG> Ладно, оставим GUI. Посмотрим в сторону поддержки популярных СУБД. Однако, тут картина и того хуже. Если VCL и Qt AG> имеют приличную поддержку СУБД, то для MFC — приходится искать и приспосабливать разные костылики, чтобы AG> выполнить совсем не сложный SQL запрос.
Да нужно просто сразу сказать, что в MFC поддержки программирования с СУБД просто нет. То лихое поделие, что
туда вставили во времена 6.0 годится только для галочки в маркетинговых статьях.
AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC.
Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п.
Например, мой лично код на MFC всегда был конфеткой...
Программируя на MFC, разработчик AG> всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода. AG> Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями. AG> Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными AG> техническими сущностями.
Не согласен. Очень сильно не согласен.
AG>c) Перенос готового класса из старого в новый проект — это для MFC также пляска с бубном! AG> Если я хочу перенести окно (в смысле — наследник CWnd), то пеернести файлы заголовочника (*.h) и исходника (*.cpp) AG> оказывается явно недостаточно. Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться, AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент). AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!
Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.
Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.
AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность.
Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ?
Странная логика...
Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть
позвоночник MFC. Вот это -- реально очень плохо и негибко.
AG> Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую AG> тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах - AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Ну... Не прав на 100%.
AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально. AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
Это не Observer
Observer -- это как раз Doc/View ...
А это -- реализация контроллеров в MVC, которые везде, во всех системах теперь отмирают за ненадобностью.
И это -- очень хорошее , декларативное решение. Например, в QT такого нет, точнее тоже есть, но оно там
спрятано из кода вообще.
AG> Это решение в стиле старого доброго ANSI C, но никак не в стиле современного C++ AG> Если я в диалоговое окно (средствами студии) добавляю новый контрол, то этот новый member класса... AG> ... с какого-то перепугу объявляется как public — вместо private (или на худой конец protected).
Да объяви его как хочешь, он вытерпит....
AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет AG> отступление от идей нормального объектно-ориентированного дизайна.
Ну и что, валидное архитектурное решение, ничего страшного. Свет клином на интерфейсах не сошёлся. В классах с COM/OLE там
наоборот интерфейсов додури.
В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но
это не интересно. MFC -- это самый что ни на есть ООП.
Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL,
и ещё много чего.
AG>Вывод: применение MFC на сегодняшний день имеет смысл в простых проектах, где важна именно легкость. AG>Для более сложных проектов — очевиден выбор Qt. AG>Для старых проектов, где этому MFC сто лет, и нет возможности/финансов перейти на что-то новое, также актуально применение MFC.
Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.
Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
Вот в таких условиях MFC точно пасует. Не потянет.
Здравствуйте, уважаемый MasterZiv, Вы писали:
MZ>Ну, тогда не могу не поучаствовать в топике
Рад приветствовать, уважаемый MasterZiv
AG>1) Легковесность. Так как MFC — это относительно небольшая объектно-ориентированная (впрочем — об этом чуть ниже)
MZ>Ну, очень удивительно слышать такое, но я тебя понимаю. В смысле, я бы сказал так же, но многие разработчики это не MZ>понимают. Для многих MFC -- это огромный и страшный монстр.
Стараюсь быть объективным. Это скорее маленькая рабочая лошадка
AG>b) Коды C++ проектов на Qt куда более читабельны и лаконичны, нежели на MFC. MZ>Не согласен. Очень зависит от того, какой проект, какой код, как написан и т.п. MZ>Например, мой лично код на MFC всегда был конфеткой...
Всё дело в том, что на MFC очень много чего лишнего приходится делать руками.
Пример: ProgressBar или ComboBox в составе ToolBar-a головного окна (для проекта MFC Feature Pack) — для MFC куча всякого кода,
дополнительные классы с переопределёнными вирт-методами и т.д.
То же самое для Qt — несколько скромных (весьма простых) строчек кода.
Замечу, что здесь не следует воспринимать что-либо как обиду (не наезжаю я на твой код), просто констатирую очевидный факт для MFC.
И мой, и твой, и самого господина Гейтса код на MFC, будет обладать всеми особенностами того, чем обладает любой мфц-шный проект.
AG>Программируя на MFC, разработчик AG>всегда связан с избыточными (техническими) сущностями, которые вполнее возможно было бы вынести из прикладного кода. AG>Даже простое диалоговое приложение (без Doc/View), изобилует ненужными в 99% ситуаций сущностями. AG>Так, вызовы DDX_Control(...), изобилующие в DoDataExchange — также на сегдня представляются мне избыточными AG>техническими сущностями. MZ>Не согласен. Очень сильно не согласен.
Мне, почему-то не припомнится аналог DoDataExchange для WindowsForms. Значит всё-таки что-то в консерватории (в M$) подправили.
А в Qt — что является аналогом DoDataExchange? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром" (весь
автоматически сгенерированный код, там вынесен в отдельные файлы, в отличие от MFC, где "всё в одной большой куче").
Насчёт DoDataExchange и прочих низкоуровневых штуковин: все они уходят корнями в стрый добрый WinAPI.
Они уходят корнями туда, даже в тех случаях, когда вроде как нет аналогичной глобальной апи-шной функции (абсолютного аналога).
Да, для конца 1990-х и начала 2000-х это было шикарно. Однако, на сегодняшний день это уже не так.
AG> Необходимо 'выковыривать' как ресурсы, так и идентификаторы ресурсов и ручками AG> переносить их на новое место. Конфликт по идентификаторам ресурсов — это отдельная проблема, нет желания её касаться, AG> просто отмечу — что она есть и портит жизнь разработчика (как всегда в самый неподходящий момент). AG> В Qt, да и в VCL, перенос — это простое копирование файлов, после чего их прописываем проект — и забываем о б этом!
MZ>Ну, ресурсы -- это отдельная тема и собственно с MFC или QT оно слабо связано.
Организация 'виджетов' в Qt кардинально отличается от WinAPI — отсюда ИМХО и "ноги растут".
MZ>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически.
Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой
AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность. MZ>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ? MZ>Странная логика...
Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC
Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции), при этом он не связан с каким либо паттерном проектирования — он
просто представляет собой атавизм, актуальный разве что для текстовых редакторов
Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) —
в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.
Насчёт документ/вид — вопрос: Почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET?
Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается.
В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны и удобны для прикладного программера, нежели документ/вид в MFC...
MZ>Вот MDI архаичен, вот это -- да, на 100%, и очень плохо, что эта архитектура фреймов врезана в самый что ни на есть MZ>позвоночник MFC. Вот это -- реально очень плохо и негибко.
MDI иногда позволяет решить проблему, а иногда создаёт проблемы. Здесь всё зависит от проекта.
AG>e) Понятие ООП в MFC какое-то половинчатое. Допускаю, что для 1990-х это было вполне даже нормально. AG> Например — паттерн observer для обработки сообщений реализован макросами BEGIN_MESSAGE_MAP/END_MESSAGE_MAP
MZ>Это не Observer
Просто одна из его (не весьма удачных) реализаций. Скажу так — Observer, но изуродованный до полной неузнаваемости
MZ>Observer -- это как раз Doc/View...
Ну, если говорить с некоторой натяжкой, то может это и Observer, но также довольно странный.
Во всяком случае, этот Observer подобен "Демьяновой ухе" — его навязывают практически без необходимости.
AG> Тот факт, что абстрактные классы в MFC не являются интерфейсами, а содержат реализацию, также представляет AG> отступление от идей нормального объектно-ориентированного дизайна.
MZ>В общем, у тебя привратное, однобокое представление об ООП, так что, ну, можно конечно тебя послушать на эту тему, но MZ>это не интересно. MFC -- это самый что ни на есть ООП.
Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET.
Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).
MZ>Код MFC тем не менее достаточно архаичен, там почти не используются шаблоны и generic programming, там не испльзуется STL, MZ>и ещё много чего.
+100500
Похоже, что MFC появился до внедрения STL — вот и объяснение.
MZ>Да нет же, всё не так. Если нужно программирование desktop UI под Windows, то фактически альтернативы MFC как не было, так и нет.
Ну давай смотреть, какие есть альтернативы и для чего:
1) .NET:
1.1. WindowsForms;
1.2. WPF;
2) Qt (здесь как под-вариант QML);
3) Java (да, несколько не нативно, но тем не менее). MZ>Не зависимо от сложности проекта. Дело в другом, что и UI только под Win уже мало кто хочет, и вообще Desktop мало кто хочет.
В определенной нише — много (даже очень много) кто хочет! MZ>Вот в таких условиях MFC точно пасует. Не потянет.
Конечно же, документооборот теперь почти весь на Web-е (что-то есть на .NET-е и что-то на Java).
Львиная доля современных технических desktop проектов — на Qt.
P.S. На сегодня desktop — это и управление IoT системами, и научные расчёты, и индустрия развлечений.
AG>Мне, почему-то не припомнится аналог DoDataExchange для WindowsForms. Значит всё-таки что-то в консерватории (в M$) подправили.
Ну так там концепция другая, там published — свойства объектов, и объекты из сохранённых образов объектной системы восстанавливаются.
AG>А в Qt — что является аналогом DoDataExchange? ИМХО его там просто нет — так как он там не нужен, т.к. там всё это "за кадром" (весь AG>автоматически сгенерированный код, там вынесен в отдельные файлы, в отличие от MFC, где "всё в одной большой куче").
.ui файлы там. По сути тоже аналог того решения, что сделано в WinFOrms.
Да, это вынесено из исходного кода, но зато если нужно что-то массово подправить -- сложнее.
Если не хочешь пользоваться визардами и средствами проектирования UI -- тоже сложнее, хотя не намного.
Но в целом, так на так и выходит, есть и плюсы, и минусы. Сравнивать это вряд ли можно, слишком разные решения.
AG>Насчёт DoDataExchange и прочих низкоуровневых штуковин: все они уходят корнями в стрый добрый WinAPI.
Да ладно, ну совсем никак не связано. Совершенно новая концепция именно в MFC для связи контролов WinAPI с контролами
формы и для связи данных из диалога с данными в форме на MFC/C++.
Где ты там корни WinAPI увидел -- сложно понять...
Ращве что только что это код, а не данные, хотя если абстрагироваться, можно DDX не воспринимать как код, а
воспринимать как специальный декларативный DSL, призваный описать какие-то аспекты работы формы. В принципе
в идеале он и должен быть таким, чисто декларативным.
MZ>>Но я могу сказать, что эти проблемы достаточно легки, потому что всё это делается механически. AG>Если в солюшене порядка 50-ти проектов, это уже превращается в нехилый геморрой
Ну ты же не будешь переделывать сразу все 50 проектов... По одному,
AG>>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность. MZ>>Здрасти, приехали... В QT Doc/View вводят (в 4.5 кажется) -- это прогрессивно, а тут -- архаично ? MZ>>Странная логика... AG>Model/View для Qt — это совсем другое, идеология Model/View для Qt — это вариант развития, он ненавязчив, в отличии от Doc/View для MFC
Ну-ну. С каого это совсем другое? Это оно и есть, MVC, Subject/Observer, классика из GoF.
Совершенно разные реализации и подходы, это да, в MVC идея взята в более чистом виде, в QT сделали
много стандартных повторноиспользуемых моделей данных, список, таблица и таблица с иерархией.
(мне кстати не очень нравится, достаточно неуклюже сделано, чистого Subject/Observer нет вообще).
AG>Пример: в MFC Doc/View навязан всегда (для MDI и даже для SDI конструкции),
Нет, не навязан он всегда, есть Dialog based приложения.
Ну да, он немного более сильно чем нужно встроен в ядро MFC, это да, и я про это уже писал.
В том числе несчастный MDI.
AG>при этом он не связан с каким либо паттерном проектирования — он AG>просто представляет собой атавизм, актуальный разве что для текстовых редакторов AG>Для Qt — Model/View это вариант архитектуры проекта (он помогает согласовать изменение данных для паттерна MVC в проекте) — AG>в самом простом случае можно обойтись и без него, создав полноценное (SDI,MDI,диалоговое) приложение с современным GUI.
Я ещё раз говорю, у тебя странная логика. Одно и то же решение, один и тот же паттерн тебе в одном случае нравится, принимается
за инновацию, в другом случае кажется архаичным и неправильным. И это при том, что в MFC Doc/View был с самого начала, с 90-ы, а
в QT появился только в 21 веке, потому что ну видимо все уже разработчики тыкали их носом в какашки и ругались, а где же у вас
Doc/View или MVC.
AG>Насчёт документ/вид — вопрос: Почему ТЕ ЖЕ ЛЮДИ не оставили эту идею в .NET? AG>Ведь ни в WinForms, ни в WPF этой навязчивой идеи Doc/View не наблюдается. AG>В ASP.NET MVC — приняты совсем иные идеи, которые куда более перспективны и удобны для прикладного программера, нежели документ/вид в MFC...
MFC и WinForms были сделаны для разных целей. MFC -- для создания Word-ов и Excel-ей, WInFOrms -- на замену VisualBasic, для создания корпоративных
приложений, состоящих в основном из таких концепций UI, как "форма". Ну, не нужны там Doc/View.
(для того же -- убить VisualBasic- создавалась и Delphi, автор идеи которой делал и WinFOrms).
AG>Ну, если говорить с некоторой натяжкой, то может это и Observer, но также довольно странный.
Без натяжек, это он и есть.
AG>Моё представление об ООП сформировалось из анализа тех решений, что есть в современных ЯВУ и прежде всего в .NET. AG>Но даже в современном C++, эти решения уже ушли от того, что принято в MFC (ушли далекооо).
Кто тебе сказал, что .net -- это образцовый ООП?
Кто тебе сказал, что современный C++ -- это ООП (только ООП)?
AG>Похоже, что MFC появился до внедрения STL — вот и объяснение.
Он появился задолго даже до момента появления мысли о STL.
Здравствуйте, AlexGin, Вы писали:
AG>d) Архаичная архитектура Doc/View (Документ/Вид) также вводит лишнюю, абсолютно неактуальную для XXI века сущность. AG> Если в 1990-е, для текстового редактора это было актуально, то теперь — это просто избыточная сущность, на которую AG> тем не менее, завязана вся библиотека MFC. Это усложнение, которое просто приходится обходить в современных проектах - AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Вот здесь не соглашусь.
Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View.
При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd.
Это и в MDI работало, и в SDI.
Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется).
Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Сам я в Doc/View от MFC много толку не вижу.
Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать.
Мне всегда было проще свой Model/View замутить.
Здравствуйте, qaz77, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>d) Архаичная архитектура Doc/View (Документ/Вид) AG> Это усложнение, которое просто приходится обходить в современных проектах - AG> напрмер, оставляяя пустой класс документа — просто для поддержки Doc/View
Q>Вот здесь не соглашусь. Q>Апп визард и в 6.0, и в современных студиях позволял отказаться от Doc/View. Q>При этом класса документа не создавалось вообще, а вместо CView подставлялся просто CWnd. Q>Это и в MDI работало, и в SDI.
Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ниже приведен пример из одного из моих старых проектов: переопределенный метод InitInstance:
m_pPhoneBookTemplate = new CMultiDocTemplate(IDR_PhoneBookTYPE,
RUNTIME_CLASS(CPhoneBookDoc),
RUNTIME_CLASS(CChildFrame), // настраиваемая дочерняя рамка MDI
RUNTIME_CLASS(CPhoneBookView));
if (!m_pPhoneBookTemplate)
return FALSE;
AddDocTemplate(m_pPhoneBookTemplate);
Вот такие есть шаблоны документов:
CMultiDocTemplate: https://msdn.microsoft.com/en-us/library/58d94y2f.aspx
CSingleDocTemplate: https://msdn.microsoft.com/en-us/library/7yha6tek.aspx
Каждый из них определяет набор: документ/окно_рамки/вид для каждого дочернего MDI (или же для единственного SDI) окна.
Этот механизм встроен в самое ядро MFC, посему его обойти, увы, не так-то просто (когда-то я экспериментировал с этим).
В реальности — проще оставить 'фейковый' (пустой) класс документа, нажели пытаться обойти фундаментальную архитектуру Doc/View
Q>Единственная известная мне фича, жестко завязанная на Doc/View, это предварительный просмотр печати (который CPreviewView, кажется). Q>Если им пользоваться, то да, только фейковые документы, док-темплейты и вьюшки.
Да, это одна из фич, завязанных на Doc/View.
Ещё интересная фича:
virtual BOOL SaveModified( );
переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
Другое дело, что все эти фичи НЕ стоят тех усложнений и ограничений, что дополнительно вносит Doc/View
Q>Сам я в Doc/View от MFC много толку не вижу.
+100500
Да, именно поэтому данная архитектура и не сохранилась, по крайней мере в таком виде как в MFC, для современных фреймворков. Q>Там все слишком ориентированно на файлы и сложно под свою задачу кастомизировать. Q>Мне всегда было проще свой Model/View замутить.
Совершенно верно! У меня точно такая же проблема.
ИМХО все равно, потребуется разрабатывать свою бизнес-логику (включая свою реализацию "документа"), посему Doc/View от MFC и теряет смысл.
Здравствуйте, AlexGin, Вы писали: AG>Как это может реально работать, если и SDI, и MDI проекты в InitInstance создают и 'регистрируют' шаблон документа?
Ну вот работает — и все.
Сейчас под рукой MSVC 2013, делаем New project->MFC->MFC Application.
Там же, где выбирается MDI/SDI/Dialog based, есть опция "Document/View architecture support".
Если галочку снимаем, то никакие шаблоны документов и проч. не генерируются, ни в InitInstance, ни где-то еще.
ChildView делается просто наследником CWnd.
AG>Ещё интересная фича: AG>
AG> virtual BOOL SaveModified( );
AG>
AG>переопределив этот метод, можем заменить сообщение о том, что юзер забыл сохранить документ.
"Сохранить документ" — это то же файлами отдает. А если у нас БД или просто на лету куда-то пишется?
К тому же есть простая альтернатива — return из OnClose окна-рамки до вызова родительской реализации.
Здравствуйте, Evgeniy Skvortsov, Вы писали:
ES>К плюсам MFC ещё можно добавить кучу визардов для VS, которые позволяют без ручного кодинга быстро и достаточно удобно добавлять новые методы, обработчики событий, переопределять виртуальные функции.
К сожалению, в современных версиях студии добавление чего-либо в исходники с помощью визардов сильно испортили.
Раньше добавлялись метки //{{AFX_... для вставки в строго отведенные места.
Сейчас такие метки не добавляются, все лепится в конец.
С namespace это добро никогда нормально не работало.
Определения функций-членов лепились за закрывающей скобкой namespace и приходилось руками переносить.
Крайне неудобно добавлять файлы (визард Add class), если файл проекта лежит не в корне папки с исходниками.
Файлы всегда норовят создаваться рядом с файлом проекта.
Для мня это актуально, т.к. одноименные .vcproj под разные версии студии лежат в подпапках.
Не много не в тему. Наболело про редактор ресурсов.
Редактирование таблицы строк в новых студиях — это просто песня. В VC6 был вполне удобный.
Импорт ресурса из файла, например иконки, добавляет в проект "res/my_icon.ico" и "../res/my_icon.ico".
Вывод такой.
В MSVC 6.0 класс визард и редактор ресурсов работали вполне сносно и его использование могло ускорить разработку.
Потом MS все испортил и теперь больше сил уходит на борьбу с последствиями.
В результате сейчас в 2013 студии класс визардом не пользуюсь вообще.
Здравствуйте, qaz77, Вы писали:
Q>В MSVC 6.0 класс визард и редактор ресурсов работали вполне сносно и его использование могло ускорить разработку. Q>Потом MS все испортил и теперь больше сил уходит на борьбу с последствиями. Q>В результате сейчас в 2013 студии класс визардом не пользуюсь вообще.
MSVC 6.0 вообще была лучшей версией студии. Начиная со следующей (2000+) её переписали на формсах,
и всё испортили (IMHO).