Рекомендации по проверке CDialog и CPropertySheet?

Question

Подскажите, пожалуйста, свой путь или дайте ссылку на лучшие рекомендации по проверке диалогов и листов свойств в приложении MFC?

У меня есть свой способ сделать это, но меня интересует любое другое мнение.

Я слышал, что макросы MFC DDX_xxx и DDV_xxx (и функция UpdateData ()) - не лучшее решение?

Как насчет проверки листа свойств?

Answer 1

Мне нравится использовать вариант Model-View-Presenter. Хорошей иллюстрацией этой практики в стиле MFC является « Диалоговое окно« Смирение »» Майкла Фезерса.

Некоторые принципы:

• Держите представление (диалоговое окно или страницу свойств в вашем случае) как можно более невежественным. Он не должен содержать фактическую бизнес-логику / логику проверки. Скорее, это должно облегчить отображение данных пользователю и манипулирование данными пользователем. Он должен уведомить докладчика о том, что что-то происходит, но он не должен «направлять» действие в каком-либо смысле.

• Модель отвечает за форму данных. В моих моделях каждое свойство хранится в структуре LimitedXXX. Например, LimitedString, имеет CString m_value, int m_maxLen, int m_minLen и AllowedChars m_allowedChars. AllowedChars - флаг перечисления, указывающий, разрешены ли целые числа, десятичные / групповые символы, буквы, знаки пунктуации и т. Д. Модель имеет только поля, она не содержит никакой логики.

• Докладчик отвечает за передачу значений модели в представление и из него и отвечает на уведомления из представления. Когда представление вызывает уведомление об изменении для элемента управления редактирования, докладчик отвечает, проверяя соответствие ограничениям, указанным моделью. Затем докладчик может выполнять различные действия в зависимости от того, является ли значение действительным или нет. Он может отображать окно сообщения и восстанавливать исходное значение, он может выдвинуть сообщение об ошибке в область уведомлений представления, он может сделать значок ошибки видимым в представлении.

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