Cost vs Payoff question, using class modules for data access (1 Viewer)

MarkK

bit cruncher
Local time
Today, 11:17
Joined
Mar 17, 2004
Messages
8,178
I recently wrote an 'Explorer' style application (using treeviews) that offers an interface for the parametric programming of the relationships between the parts of cabinets. Users can create a Build Specification, add an Assembly, add Parts to an Assembly, add an Assembly to an Assembly, and add Properties to any of these. A Property object contains an Expression object that might reference other Property.Expression objects to resolve it's Value.
Once a 'Build Specification' is programmed, the user can feed box dimensions to an Assembly and the application creates a cut list of parts.

After a huge learning curve, the solution I developed uses class modules almost exclusively for data access. One object 'cmoObject' is responsible for all data operations on the one self-referencing table 'cmtObject'. Though Access does not support inheritance, my 'cmoAssembly' object, for instance, exposes it's underlying 'cmoObject' as a read-only property, which spoofs inheritance to a satisfying degree.

In short, I'm amazed at the flexibility and stability of this 'OOP' approach. Adding new functionality doesn't break anything and passing object references seems wildly efficient. If I wanted too port the application to SQL Server for a different customer I could change the data access strategy of the entire system by tweaking a few lines of code in the base object. Cool. Wow. But, solving the problem I've desribed, given it's multitude of parent-child relationships, seems to lend itself well to this approach.

Questions:
1) Will this 'oop' approach offer the same kind of benefits in a more conventional multi-table application? For instance, I'm currently adding some functionality to an order management system I wrote last year where data access is managed by forms and subforms and I'm frustrated by the lack of class modules and my inability to access data using Intellisense features. By comparison the old, non-oop system seems to 'sprawl' and new features seem not to be able to leverage existing structures nearly as well.
2) Could or should a 'multi-table' system be coerced or otherwise re-structured somehow to accomodate a more 'oop' approach?
3) Is this experience I'm describing shared by anyone? Is 'oop' code just a way better way to get things done?
4) Are there oop problems and non-oop problems?

Observations, experiences and feedback would be appreciated since my experience with class modules is very new, but it appears to me that knowing more about these issues could save me stupid amounts of time.

Thanks in advance,
Mark
 

Users who are viewing this thread

Top Bottom