Implementing Custom Class Objects-Where should they go?

[Monterey_Manzer]

Hi Everyone,



I am trying to migrate toward using custom built class objects as a way to encapsulate the business logic in my database and I'm hoping to hear from some people who have experience with this. Once I got started with VBA coding I really started loading up most of my forms (and even the reports) with code but I am starting to see how unwieldy that can get. I've been doing some reading about building custom classes and I think I want to migrate much of my more complicated business logic to these objects. My primary database is a split dBase and I am wondering if anyone knows whether it is preferable to have the class modules used to create custom class objects in the front end or the back end database. Also, I was wondering what, if any, performance issues people may have had when implementing complex methods within custom objects.

Thanks!
Ryan

[ItsMe]

My experience with them is limited but I will throw my two cents in.

EDIT: The first code you write behind a form or report creates a form or report's Class Module. No VBA = No Class
When you write code behind a form or a report you are creating a class. As for where to put them, I would think the FE. My thought is, keep the desktop app a desktop app. If your BE is on a file server keep it as a file server. If you rely on an Application Server then consider using classes there.

I don't typically bother with Class Modules in Access. Maybe I don't create complex enough apps. I like to tell myself I am staying in the spirit of RAD by keeping my code behind the form, using intrinsic event handlers. I will depend on Standard Modules to access routines globally.

I have purchased DLL’s to act as an API. For this I will create a class. However, the code in the class I did not write. At most, I convert it to VBA. This all goes on the client machine in the instances I use them.

[Monterey_Manzer]

I figured I should likely leave all the business logic on the FE database. I just worry about the "thick client" effect and any impact on dBase performance. Thanks for the two cents!

[ItsMe]

Create a Class Module vs Standard Module so your application/FE does not reserve virtual memory for every last declaration/instantiation within your code at startup. For instance, an API I incorporate in my app may be unwieldy to duplicate behind each form. If it were in each form though, it would reserve system resources only when said form is opened. The solution is to place the code in its own Class Module.

In my case, I deem the API’s to be unwieldy and resource hogs. The other resource hogs I can split up amongst different apps according to operations and business rules, including them in Standard Modules. Splitting up apps may not work if you have a power user that sits at one desk and micromanages everything.

Having said that, there are other purposes for custom Class Modules in Access. It may be feasible to define an object to interact with Outlook or Excel or something and have code behind a form create a new instance of your Object defined within your custom Class. I do not employ this technique and do a lot of copying and pasting of code. You may want to consider this and give it a try. I have not because when it comes time, I get lazy and just keep it all behind the form.

[Monterey_Manzer]

Yeah, I have most of my stuff in Standard Modules, including modules full of Outlook, Excel, and Word automation. I guess if you haven't run into problems with all your code being behind the form then I shouldn't worry. I'll probably still poke around with some class modules and if I come up with anything that seems useful to of interest, I'll be sure to post it here.

[ItsMe]

AFAIK standard modules will burn resources. So the rule I follow is to keep it in a class unless you are willing to reserve resources demanded by all standard modules at all times the app is running. If you do not wish to allocate the client's resources to objects and variables, move them to a class. My preferred class is a Form's class or maybe a Report's class.

It sounds like you may have VBA as User Defined Functions in Standard Modules. This is OK if they are used often and this is where I may include certain UDF’s in one application vs. another application.

A Public Function in Form’s Class Module will remain private to that Class, ie the form. Close the form and the UDF is no longer available. This is a third option.