Информация об изменениях

Сообщение Re[2]: Мысли об MFC от 04.05.2017 11:56

Изменено 04.05.2017 12:27 AlexGin

Re[2]: Мысли об MFC
Здравствуйте, 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, заложенную в фундамент MFC

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 и теряет смысл.
Re[2]: Мысли об MFC
Здравствуйте, 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 и теряет смысл.