"(т.е. родитель не должен ничего знать о классе приложения, классе представления или классе документа)"
Я не уверен, что понимаю это предложение, что вы имеете в виду под словом «родитель» здесь?
В любом случае, по моему мнению, дизайн, который вы описываете, на самом деле не является проблемой. Это компромисс: передаете ли вы эти классы всем функциям, которые в них нуждаются, усложняя их использование и API, или же вы храните их в виде глобальных переменных, как вы делаете? Это зависит от данных, к которым осуществляется доступ, и как часто. Данные, которые нужны во многих местах, также могут быть «глобальными».
Есть несколько способов сделать данные «глобальными»: сделать их членом CWinApp (то есть, вашего производного от CWinApp класса), или CMainFrame, или вы делаете фактическую «глобальную переменную», или вы делаете синглтон, ...
Проблема с глобальными переменными состоит в том, что становится трудно определить, кто и когда получает к нему доступ. Если вы данные как член CWinApp, вы можете получить к нему доступ через функцию доступа и отследить доступ оттуда (через сообщения журнала, точку останова, ...). Это, на мой взгляд, уменьшает большинство проблем, связанных с глобальными переменными. В настоящее время я обычно использую синглтон Loki.
Причина, о которой говорится в вашем сообщении о том, что данные не являются членами CWinApp, как проблема развязки, заключается в (в контексте, который вы ее представили) немного странной вещи. Если определенные классы нуждаются в доступе, им все равно нужно будет знать об этих структурах данных, и их местоположение хранения не имеет значения. Может быть, это только потому, что я не знаю о специфике вашего дизайна.