MDI Doc/View CDatabase app general questions
-
I am writing a MDI database app using a splitter window (upper pane = parent table) (lower pane= child table) and am unsure as to the responsibilities of each class. I have it working but am always trying to better myself. I have a database object (CDatabase) I have a recordset object (CRecordset) I have a document object (CDocument) I have several views (CFormView) I have a CSplitterWnd hosting the CFormViews I realize the document holds the data. So here are my questions I have seen an example where the document holds a member variable of both the Recordset and the Database and am currently adopting this scenario. But which class is responsible for actually creating the recordset or does it matter? I currently have the document creating the database and each formview class responsible for creating the recordset of its pane. My document holds a member pointer of the recordsets created in the view Is it appropriate to use the UpdateAllViews from the CDocument class to invoke the OnUpdate of each view? Then overide the OnUpdate in the view class to run a requery and other housekeeping procedures. Normally I associate the UpdateAllViews with some sort of visual activity in the Views but with a database it's all about requerying and housekeeping. Thanks
-
I am writing a MDI database app using a splitter window (upper pane = parent table) (lower pane= child table) and am unsure as to the responsibilities of each class. I have it working but am always trying to better myself. I have a database object (CDatabase) I have a recordset object (CRecordset) I have a document object (CDocument) I have several views (CFormView) I have a CSplitterWnd hosting the CFormViews I realize the document holds the data. So here are my questions I have seen an example where the document holds a member variable of both the Recordset and the Database and am currently adopting this scenario. But which class is responsible for actually creating the recordset or does it matter? I currently have the document creating the database and each formview class responsible for creating the recordset of its pane. My document holds a member pointer of the recordsets created in the view Is it appropriate to use the UpdateAllViews from the CDocument class to invoke the OnUpdate of each view? Then overide the OnUpdate in the view class to run a requery and other housekeeping procedures. Normally I associate the UpdateAllViews with some sort of visual activity in the Views but with a database it's all about requerying and housekeeping. Thanks
It depends. IMHO, it would be much better to hold your CDatabase and CRecordset objects together in the CDocument-derived class of yours because they are essentially serving the same purpose - to link your views to data. However, if recordset objects are subject to heavy dynamic user-invoked changes, I'd normally prefer to associate them with views. That's what I think, although it's so much more a matter of preference than of being right or wrong...
-
It depends. IMHO, it would be much better to hold your CDatabase and CRecordset objects together in the CDocument-derived class of yours because they are essentially serving the same purpose - to link your views to data. However, if recordset objects are subject to heavy dynamic user-invoked changes, I'd normally prefer to associate them with views. That's what I think, although it's so much more a matter of preference than of being right or wrong...
-
Thanks, Does it matter where those recordset objects get instantiated with the new keyword (CDatabase or CFormView)?
Yes, it does matter for me. I'd create them immediately where they are used, but also exactly where "main" pointers to them are stored (i.e. those pointers you use to delete recordsets; it's important as this must be done only once and preferably in a function called from the destructor of your CDatabase or CFormView object). The worst thing to do IMHO is to split the code that works with these recordset objects into several parts based in different classes. Chances are all hell will break loose upon you when: a) execution flow comes to destruction and oops you overlook a leak or delete objects twice or whatever else... b) the program swells in size and soon you are no longer able to track down all activities associated with recordsets. Keep it simple. In the end it's much better to misplace pointers but code consistently keeping in mind this architecture than to make a correct design decision (if there is one) but implement it inconsistently or in a sophisticated manner.