Создается приложение, которое должно отражать данные структуированного файла и сохранять этот файл, если пользователь изменил какие-нибудь поля структур. Структуированный файл состоит из трех структур. Структуры созданы так, что один из членов первой структуры содержит указатель на вторую структуру, а один из членов второй структуры содержит указатель на третью структуру. Таким образом они связаны один ко многим. Но это не суть. Вопрос связан с выбором архитектуры для этого проекта. Сам проект должен быть реализован на VC++7.0(MFC). Как известно MFС поддерживает архитектуру "Документ\Представление". Наши идеи вот какие:
1.) Это будет приложение SDI;
2.) Вид (главный вид) связанный с главным фреймом приложения будет порожден от CFormView и для этого фрейма будет единственным.
3.) Приложение должно иметь три области разделенных сплитером. В первой области будут отражаться данный первой структуры, во второй второй и в третей третий. И все эти области должны находиться на CPropertyPage, а количество CPropertyPage должно равняться пяти. Таким образм пять вкладок каждая из которых делиться на три части двумя сплиттерами. Чтобы это реализовать мы решили на главном виде приложения создать пять вкладок, а на каждой из вкладок создать сначало один фрейм со статическим сплиттером и двумя видами от CFormView. Потом в этой же вкладке создать в левом виде еще один фрейм со сплиттером и двумя видами от CFormView. Таким образом у нас есть все представления для отображения данных в все фреймы их поддерживающие.

Вопрос: Исходя из данной стуктуры приложения как наиболее эффективно применить к ней архитектуру MFC "Документ\Представление" и нужно ли это делать с точки зрения эффективности дальнейшей поддержки и сопровождения.

Спасибо.

Хотелось бы использовать только возможности MFC не привлекая другие технологии, особенно возможность MFC с точки зрения проектирования архитектуры системы и физическом ее воплощении.

Спасибо.

В данном случае документ - это все данные, находящиеся в структурах. Но у нас не одно представление для того, чтобы данные этих структур, а именно данные документа, в нем отразились. У нас несколько представлений, а конкретно для каждой структуры свое представление и все они находяться на разных фреймах. Исходя из этого, можно предположить что в данном проекте должно находиться столько документов завязанных на один шаблон документа, сколько структур, а еще точнее представлений. Таким образом у нас появляется нормальная связка для каждой структуры: Документ - Фрейм -Представление. Но по моему - это плохой вариант, так как нет единого документа или единого источника данных, то мы не сможем более или менее лаконично централизованно управлять представлениями.

Как можно сделать так, чтобы имея один документ и несколько представлений расположенных на разных фреймах их завязать. Представления созданы методом CreateView класса CSplitterWnd.

И еще, если я не прав, то обязательно поправьте. На мой взгляд преимущество архитектуры "Документ/Представление" заключается именно в централизованном управлении представлениями конкретного документа. Т.е. переопределяем у каждого представления OnUpdate(). И одним вызовом UpdateAllViews контролируем всю ситуацию. И больше никаких преимуществ она не дает.

Спасибо.