Correct way to use Document object when not persisting using Serialisation 
Author Message
 Correct way to use Document object when not persisting using Serialisation

I am in the process of designing my app (in an attempt to do it properly
instead of bodging together code later on), and will be using an ATL COM
layer to access a database which is what will contain the application's
data.

The actual data is in the form of folders and items, so the COM server
includes interfaces (for example) such as IFolder and IItem. These in turn
provide properties with the relevent data.

Is it a good idea to introduce another layer by producing C++ classes to
wrap the COM calls? It might mean changing things in two places in the
future, but at the same time it would reduce the places where I have to put
so many QueryInterface calls :)

Then, the next issue is, how does the Document model fit in with this
design. Should the Document object include members for the Folders and
Items, bearing in mind that the Items will be changing when a folder is
changed etc.? Should the document just include functions to return the
necessary details, and then these functions get called when a view needs the
data etc.?

Any suggestions would be greatly appreciated,

Paul



Thu, 27 Jan 2005 05:28:28 GMT  
 Correct way to use Document object when not persisting using Serialisation
Paul,

your question is a recurring one, and the biggest issue is the Microsoft
named the CDocument class.  We tend to think of document as something akin
to an MS Word application, i.e. something real that has pages.  That's not
at all what the CDocument class represents.

If one thinks of the View as the rendering of some information, or the
graphical interpretation of some data, and the Document as a storage for
that data, hopefully, the picture get a bit clearer (note: the document does
not have to persist the data to be of value, its tight integration with the
View makes it a handy runtine storage container).  Contrast the MFC approach
with a more unstructured approach - writing an application and implementing
all of the code in the _winmain, doing the data handling and drawing and the
user input/interaction in that one grand monlithic thing.  If you see this
later as a problem, then you may think of MFC as but one of several
solutions available....

MFC is a framework, and as such proved but one way to do the task.  If you
like that way, and/or if you can fit your application into that framework, i
think you will see a substantial productivity boost (but there is a
substantial one time cost of figuring out just what the framework is doing
and how to use it).

Each of the public/virtual methods can be thought of as a hook, and whether
or not you use the hook will depend on your application, and where the hook
is called during the life of the application.  Consider these sequences of
activity in the CDocument:

1) c-tor->OnNewDocument->DeleteContents as response to OnFileNew event,

2) CloseDocument->DeleteContents->d-tor as response to OnFileExit event

3) c-tor->OpenDocument->DeleteContents as response to OnFileOpen event,

these are from the SDI model, where the document object is continually
reused, ergo the many calls to DeleteContents.  It is called dirung open dto
allow initialization.  it is called during close to allow resources to be
freed.

Whether you access all of the data and store copies of it during CDocument
initialization, or merely provide accessor methods in the document to fetch
these data on demand is very much design-specific issue.  what may be good
in one case may not be appropriate in another -- but just that you were
aware of the the two possibilites suggests you are well on the right track.

regards
roy fine


Quote:
> I am in the process of designing my app (in an attempt to do it properly
> instead of bodging together code later on), and will be using an ATL COM
> layer to access a database which is what will contain the application's
> data.

> The actual data is in the form of folders and items, so the COM server
> includes interfaces (for example) such as IFolder and IItem. These in turn
> provide properties with the relevent data.

> Is it a good idea to introduce another layer by producing C++ classes to
> wrap the COM calls? It might mean changing things in two places in the
> future, but at the same time it would reduce the places where I have to
put
> so many QueryInterface calls :)

> Then, the next issue is, how does the Document model fit in with this
> design. Should the Document object include members for the Folders and
> Items, bearing in mind that the Items will be changing when a folder is
> changed etc.? Should the document just include functions to return the
> necessary details, and then these functions get called when a view needs
the
> data etc.?

> Any suggestions would be greatly appreciated,

> Paul



Sun, 30 Jan 2005 03:51:27 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Using types in a different assembly given that the type may be used or not used

2. Document not displayed when using shortcut to run app

3. Persisting State - Without using session vars

4. How do i persist binary data(Picture) using IPersistPropertyBag

5. CRITICAL_SECTION seem to have an event object if not using the spinlock

6. Attributes not created when ConstructorInfo.Invoke used to create object

7. How to Embed Microsoft Word Document without using document view architecture

8. COleClientItem from Word Document using a document template

9. Event handler using a control variable and not using message map

10. design problem using c++ : casting to correct template.

11. Cannot get correct TAB order when using MSMASK32.OCX in Property Sheets

12. What is the correct way of using SendMessage to send CTRL-A

 

 
Powered by phpBB® Forum Software