Hi. I used a deliberately (semi-)provocative title for my question. 
I've written tens of thousands of lines of VBA code in many Access databases for my employers over the last several years, but am primarily "self-taught". I have no compsci degree. I've never used a class module in any of my databases, and have always worked with the data layer going directly to the forms and vice versa. That is, I create forms (bound and unbound; usually unbound) with controls, and save the entered data directly to a DAO recordset.
Recently I examined a friend's Access app. It's huge, and uses regular code modules (which I use all the time too) and _class modules_ (which I had never used before). I figured out where the classes created/defined in these modules seem to fit in the app's design:
*- User Interface "layer": (Forms, controls, etc.) --> send/receive data to/from...
*- Class "layer" (defined in class module) --> receive/write data to/from...
*- Data (or disk file) layer (the Access tables) --> read/write data to/from the class
What I don't understand is: why insert this "class layer" in between my forms and the data layer? If "safety" in the retrieving/writing is a concern, I can read/write within a _transaction_, can't I?
Why can't I leave a application's forms save (for example) its controls' data directly to tables (internal or external/linked) within a transaction? I've just recently learned the function (basics) of transactions, and they seem like a very robust way of "protecting" your critical reads/writes. So why would I want/need to insert another layer of complexity, the _class module_?
I should add I never formally studied OOP principles; so I really missed out on learning the advantages of using classes (if one can put it that way!). Please be gentle with your responses; I'm really trying to learn! Thanks.
Thooom
I've written tens of thousands of lines of VBA code in many Access databases for my employers over the last several years, but am primarily "self-taught". I have no compsci degree. I've never used a class module in any of my databases, and have always worked with the data layer going directly to the forms and vice versa. That is, I create forms (bound and unbound; usually unbound) with controls, and save the entered data directly to a DAO recordset.
Recently I examined a friend's Access app. It's huge, and uses regular code modules (which I use all the time too) and _class modules_ (which I had never used before). I figured out where the classes created/defined in these modules seem to fit in the app's design:
*- User Interface "layer": (Forms, controls, etc.) --> send/receive data to/from...
*- Class "layer" (defined in class module) --> receive/write data to/from...
*- Data (or disk file) layer (the Access tables) --> read/write data to/from the class
What I don't understand is: why insert this "class layer" in between my forms and the data layer? If "safety" in the retrieving/writing is a concern, I can read/write within a _transaction_, can't I?
Why can't I leave a application's forms save (for example) its controls' data directly to tables (internal or external/linked) within a transaction? I've just recently learned the function (basics) of transactions, and they seem like a very robust way of "protecting" your critical reads/writes. So why would I want/need to insert another layer of complexity, the _class module_?
I should add I never formally studied OOP principles; so I really missed out on learning the advantages of using classes (if one can put it that way!). Please be gentle with your responses; I'm really trying to learn! Thanks.
Thooom
