In the following linked message, I started creating a form and within the form code module I created some local variables to store a class object for accounts and then used the Form Current event to test the form to make sure it was valid before running the Account calculation function.

Tenatively laying out an application structure | Access JumpStart

This is just a beginning example of separating out responsibilities from the form.

I discussed a Model-View-Controller type architecture in this message:

Why, Jon, Why??? For the love of VBA, Why????? | Access JumpStart

Putting this together, how can I further isolate the form itself as simply a View type component of the system?

I think I need a larger concept of an application itself.

Let’s call this: Debt Snowball App

In this app I need to be able to input information about different debts from the client and I want to be able to output the time it will take to payoff each debt individually and also in relation to all the other debts if I use the snowball method.

I will define the snowball method (programmatically) as starting at the minimum payment for each debt and keeping the sum of all the minimum payments the same each month (not reducing the payments, but just continuing to apply them to payoff the smallest debt, then the second smallest debt, and so on).

' The main app structure
'Class: The Debt Snowball App
'Method: Calculate Snowball Payoff Date for all debts
'Method: Load Debts
'Method: Save Debts
'Method: Create New Debt
'Method: Edit Existing Debt
'Property: Collection of Debts

In the above definition, I’m going to need a new Debt class to represent a single debt:

' The Debt class structure
'Class: The Debt Class
'Method: Update this debt
'Method: Delete this debt
'Property: Account Name
'Property: Minimum Payment
'Property: Debt Balance
'Method: Calculate Payoff Date

With the above structures, I have now removed the form itself from the application.

I could use the Edit Existing Debt method in the App class to launch the form as a view for the user to manipulate the Debt object. I could load the data into the controls and use the Debt class methods to view and capture the input from the user to pass messages to manipulate the Debt data according to that input.

I think using this structure could help us separate business logic from the user input. This abstraction would potentially allow different input interfaces, like inputing data from a text file or a command console.

I will continue moving this forward and see what happens in future messages!