Прошу меня извинить, что отвечаю по порядку всем сразу.

//////////////

to olk

>> Вообще то всегда считал, что Doc/View - это дальнейшее абстагирование ООП

Я бы сказал попытка мелкософт. Продукт коммерческий. Ну должны ж они были хоть шото дать визардовое да ещё с «абстракциями». ИМХО тоже касается DDX.
>> кхм и как-же он должен его обрабатывать ? а если я нажал кнопку отмена, контрол поля ввода >>сам должен вернуть предыдущее значение в свою буферную переменную ?

Сам программер должен написать код для обмена данными между гляделко-печаталками и контролами и буферами.


>> и чем вам ддх не угодил ? это же просто механизм (просто более универсальный) сохранения контролами своих значений в буферных переменных ...

Потому, что в реальных приложениях БД структура буферов значительно сложнее одной переменной или их простой совокупности (списка или перечисления). Как врач говорю, а не как практикующий программер БД.

>> посылается UpdateAllView - "вид" соответсвено считывая текущее состояние документа может енэйблить или дизайблить соответсвующие контролы

Эта архитектура не единственная. Очень прязана к МФЦ. Что делать, если программируем с использованием гольного API?

///////////////////////////////////////////////////////////////////////////////////////////////


To Mik Prokoshin

>> …оформить результат в виде готовых компонент/библиотеки классов и закинуть на какой-нибудь…

Если речь и не идёт о разработке архитектуры, то идёт об отказе от стандартной архитектуры, в том числе и от документ-вид, и о том, как это сделать с меньшими «нарушениями правилами уличного движения ООП».

>>Из Вашего первого поста :
>Удобство заключается в том, что всё управление отображением и заполнением контролов (enable, visible и т.д) сосредоточено в одном месте. Вернее сосредоточена общая логика приложения в части управления контролами

Да это было в посте. Там это для затравки, масло в огонь.


>> … Просто надо было сразу декларировать четко цели.

Вы правы.

>>….Если мне надо передать сообщение для группы контролов - я передаю сообщение их общему >>родителю, который и обрабатывает его, модифицируя детишек. Это можно выносить в >>отдельный шаблон, как предложено, но IMHO объем работы практически сопоставим

Вы правы, если мы обсуждаем одно и тоже. Впрочем, Вы можете быть правы в любом случае. На одном из форумов в развитие этой архитектуры предлагается отнаследоваться всем заинтересованным классам, в том числе аппликации, от месангера. Тогда, такой класс можно рассматривать в качестве контейнера-посредника (медиатора), который будет рассылать мессаги объектам-подписчикам. Тупой пример, хотя там это и не надо, - CTabPageControl:CTabCtrl:CMessanger. В этом примере диалоги пейжей могут быть подписчиками медиатора CTabPageControl. Пример тупой, т.к. для табов это решается проще. Вы об этом? Если, да то я об этом думаю.

>> Надо сразу четко оговаривать область применения. А то - сделали что-то и стали решать "вещь получилась хорошая, но куда прикрутить никак не поймем" :-)

Я уже выше попросил меня простить.
>>Просто эти идеи (в данном случае) - реализация старых шаблонов. (без обид)

Без обид. Тем более, что верно. Это было реализовано, правда в более могутном масштабе, на plain-C в начале 90. Не помню когда точно. Тогда не было виндовз, а не то чтобы хотелось, просто досовы подзадачи требовали GUI (делали самопальный ГИС). Но там было всё сложнее, поскольку тулз создания абстакций приходилось моделировать на С вместо использования языковых средств С++ описания абстракций.

///////////////////////////////////////////////////////////////////////////////////////////////

To gardenman

>>1)одну и ту же запись открываем в двух окнах..
>>2)начинаем редактировать - то в одном окне, то в другом окне...

Что здесь сказать…

>> Это конечно можно реализовать, но стоит ли усложнять код ради этого?

Задачи бывают разные. Но усложнять, думаю, не стоит. Это (выше) не усложнение, а прямой путь к краху проекта при его модернизации, наращивании и т.д., ИМХО.


///////////////////////////////////////////////////////////////////////////////////////////////

To Mik Prokoshin

>>А как Вы проектируете базу ? Не опираясь на документы (объективные понятия предметной отрасли) ?

Для данных создаётся свой класс, который умеет читать, писать и т.д. Объект такого класса и есть реализация буфера.


>>olk уже ответил, хотя мне непонятно, я сколько видел примеров работы с БД на VC - всюду DDX использовали и не жаловались.

ИМХО просто это лишнее, т.к., например, по нажатию кнопки «Сохранить» всё равно придётся «переносить» данные в буфер, возможно сложной структуры, а только потом вливать из БУФЕРА в базу. Если этого не сделать, то затруднительно нормально обработать серию транзакций.


///////////////////////////////////////////////////////////////////////////////////////////////

To gardenman


>>я иду не от документов а от сущностей)

Прально гришь.


>>Скажите пожалуйста, и сильно вам помогает CDocument в вашем случае?
>>Вы же максимум 5% от всех зашитых в него возможностей используете!
>>А остальные 95 - дописываете сами)

У меня другой вопрос. Какие вообще есть методы класса CDocument для работы с БД.
Что там «хорошо» на 1%? То что специализированный класс, да ещё умеет говорит UpdateAllViews? А свой класс, чем будет хуже? Тем, что не умеет говорить UpdateAllViews? И всё???

///////////////////////////////////////////////////////////////////////////////////////////////


To vdimas

>>to void_123:
>>это шутка????!!!
>>цитирую:

>>void CMyApp:: ClearControls()
>>{
>>m_pMainDialog.ClearControls();
>>m_pTreeView.ClearControls();

Это гипербола. Пример несколько теоретизированно-натянут.
Если класс контейнер умеет перечислять «детей», как например, CTabCtrl, то он сделает это.


///////////////////////////////////////////////////////////////////////////////////////////////


to olk


>>1. "Горизонтальный" подход (подход void_123)- когда некотое "представление" само за себя отвечает и вроде как имеет способы общения через контролы общаться с БД и другими представления ... т.е. есть некая форма которая посредство инкапсулируемых (и/или наследуемых методов) очищает , заполняет поля, верифицирует, порождает обмен с БД и т.д ...


Не сердитесь, но это очень поверхностный взгляд. Неверна даже терминология. Я понимаю, что мой стиль изложения оооооочень нудный. И оооочень тяжело прочитать. Даже мне самому;)))