From my message yesterday:
Separating business logic, user interface, and data persistence in a real world Access app | Access JumpStart
I laid out a potential structure which included

• a Table which would be a data persistence layer
• a Form which represents a user interface
• a Class which represents the business logic we need to perform on data

So how does this play out in terms of responsibilities for these components?

The table / data persistence layer is there to store data so when we close out the app and do something else, we can come back to the app and retrieve our data. It is persistent. We don’t have to re-enter it every time. This layer allows us to store data to use later and retrieve data that we previously stored to continue working with it.

That’s pretty straightforward, right?

The form / user interface layer provides a way for a human to see the data and work with the desired data, adding more, modifying what’s there, and deleting data we won’t want anymore. Really, it doesn’t have to be a human though, does it? It could be an automated script that loads records in from some other source or operates on them. Maybe just “interface layer” would be a more apt description. But anyway, this layer must provide ways for the user to do something. Commands like clicking a save button, Text Box controls to display or change data. Create event hooks to listen to which trigger other events or display or data changes.

That one seems a little more fuzzy to me.

Finally, there’s the class with the business logic which would be responsible for manipulating the data according to interactions and events occuring in the user interface.

As I was thinking about this, I realized that I was reminded of the Model-View-Controller design architecture. A quick question to Copilot produced this little summary of how that relates to Access:

• Model: This represents the data and the business logic of the application. In Access, the model is typically composed of tables, queries, and relationships that define how data is stored and manipulated.
• View: The view is the user interface that displays the data. In Access, forms and reports serve as the views. Forms allow users to interact with the data, while reports are used to present data in a structured format.
• Controller: The controller handles the input from the user, processes it, and updates the model or view as necessary. In Access, this role is often fulfilled by macros and VBA (Visual Basic for Applications) code. These scripts manage user interactions, such as button clicks or form submissions, and ensure that the appropriate actions are taken.

So the Model would generally align with the Data Persistence layer. I think I would remove the idea of business logic from this layer and move it over into the Controller.

The View description more succinctly states what I was thinking. It’s functions though are not ONLY displaying and interacting with the data itself, but contains other controls like buttons that will provide places for the user to interact. In that sense there is a kind of coupling between the user interface and the controller, but should be mainly interested in it’s particular user type and what they need to do.

Finally, the Controller would align well with a class, although in Access can be fully and easily coupled into the Form. In other words, Access forms easily allow you to embed macros and code directly into the structure of the form. BUT, you can certainly move the Controller functions to a separate class which would be responsible for carrying out the actions the user is directing through the form.

Now, the real question is why would we want to do this?

I think by separating the responsibilities of code and objects and tables allows for more flexibility to design new forms or reports which can share functionality where needed or provide new and different functionality.

For example, in our potential credit card payoff app, we could have individuals who are entering credit card information using one form, while having another form to combine payoff information for multiple users for a husband and wife. Or a business with multiple employees using company credit lines.

You could interact directly with the Controller modules via an automated script (as opposed to a form) to import card statements of employees using the same routines to validate data and save records.

In upcoming messages, I will try to use some of these principles to separate responsibilities for the app I began to define.