Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

I am currently discussing a credit card payoff application I’m working on in terms of Model-View-Control architecture in a series of messages.

In this message, moving back to forms, I have built a form (user interface) which I am going to think of as the user interface or perhaps borrowing from Uncle Bob’s Clean Architecture: a Presenter object.

I want to try to focus on the form simply presenting information to the user and balance the benefit of the built in data management of a bound form which will allow you to create new records, edit existing records and load existing records.

I have a single function I am thinking of right now for this database.

So far I haven’t written any tests. Before I do that, I want to think about the architecture of the controller here.

I don’t want the controller to depend on the form, I want the form to depend on the controller.

I want to create a function that will calculate the number of months in which a single account would be paid off if paying the minimum payment each month.

When the form loads a record then I want it to display this data. If the form does not have enough data to calculate the answer, then it should not display anything. Once the user has entered all the information into the current record or changes a number that would affect the calculation, it should be recalculated and redisplayed.

There will need to be an interface for the application to be defined by so that the form can instantiate it and calculate the value, but there is a lot more at play here.

The form and controls have events to inform the app what the user is doing. The form can run code or macros held inside the form itself. We could also use an external class which could listen to the form and controls we are interested in.

So considering all this, what kind of program flow am I looking for?

  • form defines a variable using an interface (with a method that can calculate the months to payoff)
  • form sets the application controller object which implements the interface as a local variable
  • the above steps could be performed through a function to allow lazy loading of the variable only when it’s needed
  • User loads record
  • form announces “Current” event
  • form provides data to months to payoff function the local variable (or function) and if the info is filled in correctly, the function returns data to place into the Months to Payoff field for that record.

This is one possible architecture. I’ll look at setting that up in my app and we’ll see how that changes my thoughts in tomorrow’s message 😉