Современный MFC-проект. Вопросы по доступу к данным и архите

[NightFlier]

Начинаю новый MFC-проект. Делаю его MFC, чтобы побыстрее налабать и забыться. Проект большой, и в частности, предполагает хранить данные в местной базе для внутренних SQL запросов. База небольшая, по объёму её вполне потянет MS Access.

Запускаю Wizard из-под Visual Studio 6, и он мне начинает вопросы умные задавать. А как на них отвечать я не знаю, так как последнее время всё ушло на работу на Яве, Оракле и Юниксе.

Скажите, а в чём реально разница между доступом к данным через DAO против ODBC или OLE DB?

Потом для доступа к Акцессным файлам, в чем разница между Microsoft ISAM & Microsoft Jet (там почему-то даётся выбор из версий Jet 3.51 и Jet 4.0). И что это за такой новый тип Recordset - "Table"? Очень мутное объяснение в Help дано.

Помимо того, насколько на ваш взгляд удобна реализация на MFC, стоило ли разрабатывать в Document-View архитектуре, или всё-таки лучше и проще писать всё на голом C++ с прицелом на переносимость системы.

На Си я не могу, так как нужны перегружаемые операторы, ввиду работы с динамическими типами данных.

[EugeneK]

Начинаю новый MFC-проект. Делаю его MFC, чтобы побыстрее налабать и забыться. Проект большой, и в частности, предполагает
Помимо того, насколько на ваш взгляд удобна реализация на MFC, стоило ли разрабатывать в Document-View архитектуре, или всё-таки лучше и проще писать всё на голом C++ с прицелом на переносимость системы.

Zabitsa pri bolshom proekte ne poluchitsa.
Rabotat stoit. Zdes primer dlia MFC-OLE DB:
http://cpplab.com/Articles/CSQLQuery/CSQLQuery.html

[DenisM]

...Скажите, а в чём реально разница между доступом к данным через DAO против ODBC или OLE DB?

ODBC это generic interface, который работает не только с Access, как DAO, а с любой базой, для которой есть драйвер. Если есть вероятность, что возможностей Access может не хватить в будущем, лучше использовать ODBC. С другой стороны, DAO предоставляет большую гибкость при работе с mdb базами, чем ODBC ( сравните CRecodset vs CDaoRecordset ).

Потом для доступа к Акцессным файлам, в чем разница между Microsoft ISAM & Microsoft Jet (там почему-то даётся выбор из версий Jet 3.51 и Jet 4.0). И что это за такой новый тип Recordset - "Table"? Очень мутное объяснение в Help дано.

Jet 3.51 vs Jet 4.0 - это просто engine от разных версий Access, я бы использовал последнюю.

Access 2.0 Jet 2.0
Access 95 Jet 3.0
Access 97 Jet 3.5
Access 2000 Jet 4.0
Access 2002 Jet 4.0

Table позволяет менять структуру базы во время исполнения программы ( добавлять/удалять поля, индексы etc ).

Помимо того, насколько на ваш взгляд удобна реализация на MFC, стоило ли разрабатывать в Document-View архитектуре, или всё-таки лучше и проще писать всё на голом C++ с прицелом на переносимость системы.

На Си я не могу, так как нужны перегружаемые операторы, ввиду работы с динамическими типами данных.

Document-View работает ок пока Вы не начинаете пытаться сделать что-то нестандартное, шаг вправо-шаг влево - начинаются большие проблемы из-за просчетов в реализации Document-View by MS. Не то, чтобы совсем неразрешимые, но придется много изучать MFC sources, чтобы обойти все подводные камни.

[Big Cheese]

Я бы подумал насчет использования ODBC или OLE DB, но не DAO (см. пост DenisM). Причем в случае OLEDB / C++ IMHO лучше использовать ATL's OLEDB consumer templates. На "голом" OLE DB писать довольно сложно, обычно используют либо связку VB/ADO (ActiveX Data Objects - ole autmation wrapper around OLE DB), либо VC++/ATL. Вообще, если нет реальной необходимости, я бы не стал связываться с MFC, особенно для большого проекта. В качестве альтернативы IMHO есть смысл посмотреть в сторону C# & WinForms. Аргументы:
- приличная run-time class library
- наличие ADO.NET для написания database client apps.
- удобно ваять сложный GUI
- легче переходить с Java
- много дешевых 3-rd party components вполне приличного качества

Насчет использования чистого С++ для переносимости - поясните, о какой переносимости идет речь? Если cross-platform - то думаю, что вряд-ли что-то получится, хотя вроде есть какие-то реализации ODBC на юниксах, но я бы сильно на это не расчитывал...

[NightFlier]

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

Кстати, разьве нельзя в Statement выполнять команды типа alter table dbo.whatever add new_column char(1)? Тогда какой смысл в существовании Recordset типа Table?

Спасибо относительно сомнений по поводу Document-View.

Что касается переносимости, то думалось, что отказавшись от MFC можно было было бы сделать что-то кросс-платформенное с уровнем изоляции для реализации интерфейсных функций. Но если эти интерфейсные функции реализованы классами MFC для Windows-платформы, то написание их аналогов для других систем потребует уже куда большего геморроя, насколько мне думается.

Насчёт Си-Шарп я не очень уверен - всё-таки это совсем окончательный уход в сторону Windows.


ЗАБЫЛ СПРОСИТЬ - существует ли в C++/MFC наконец нормальный менеджер памяти? Или до сих пор по старинке нужно держать в башке все динамически выделенные массивы?

[umf]

ЗАБЫЛ СПРОСИТЬ - существует ли в C++/MFC наконец нормальный менеджер памяти? Или до сих пор по старинке нужно держать в башке все динамически выделенные массивы?

В C++ нету и никогда не было гарбадж коллектора, если Вы о нем.
Для хитрых контейнеров пользуйте STL.

[DenisM]

...
Кстати, разьве нельзя в Statement выполнять команды типа alter table dbo.whatever add new_column char(1)? Тогда какой смысл в существовании Recordset типа Table?

Можно и так. С Table, может быть, удобнее, не надо возиться со строками.

Спасибо относительно сомнений по поводу Document-View.

Что касается переносимости, то думалось, что отказавшись от MFC можно было было бы сделать что-то кросс-платформенное с уровнем изоляции для реализации интерфейсных функций. Но если эти интерфейсные функции реализованы классами MFC для Windows-платформы, то написание их аналогов для других систем потребует уже куда большего геморроя, насколько мне думается.

MFC и кросплатформенность плохо сочетаются, лучше забудте об этом.

...ЗАБЫЛ СПРОСИТЬ - существует ли в C++/MFC наконец нормальный менеджер памяти? Или до сих пор по старинке нужно держать в башке все динамически выделенные массивы?

Нет, но почему бы не использовать smart pointers?