<some detailed comparison
I wrote "some detailed comparison" before Joe's post, and then couldn't post the response. I'll respond to Joe's first, and then put what I wrote.
<In VBA, the best I could do is cut & paste code from Dinosaur into TRex and Pterodactyl
Joe, you can do a little better than that. You can create a reusable component in Access, by doing the following:
1. Create a separate Access application (say "ServerApp") to hold the reusable class.
2. Add a class module or modules. Set their instancing property to PublicNotCreatable.
3. Add a standard module. In this module, create a method for each class module that returns an instance of it.
4. In applications that are using these classes, add a reference to the ServerApp application.
5. Instantiate the classes in the standard manner.
VB is often chastised as not being an OO language because it doesn't have inheritance. If the definition of OO is that it include inheritance, then so be it. However, I define OO as having primarily the characteristic of functional encapsulation. Encapsulation means that you place boundaries around some sort of functionality, and then expose that functionality in a consistent manner through a known interface.
Now then...
<separating the "business logic" into a separate layer and / or creating classs modules is easily done in Ms. A.
It really depends on how you are going to define "separating". Class modules in Access aren't capable of having a public interface, relying instead on the public interface of the Access EXE itself. So, while you can go into the Access VBA IDE and create a class module, you can't completely separate it from the application that created it.
Access class modules are actually specializations of the Access.Application object, meaning that your compiled business logic component must include the entire Access Application interface (see
This tends to contradict the point of view that the business and presentation logic are really separated into different layers. While they may have the appearance of being separated in the IDE, they're really all piled together in the same component.
Another point of comparison is that you are limited to interprocess (out-of-process) communication, which, while it has some security advantages over intraprocess (DLL-based) communication (a fatal error in a dll will hang its associated exe, but a fatal error in an exe won't hang another exe), is also much slower owing to marshaling requirements. While EXE components have their place, DLL components find much broader application than EXE components.
So, you can't create a separate DLL using Access Class modules, and can't create any objects at all that have a context that's completely separate from an Access application exe. Therefore Access classes are less strongly encapsulated "under the hood" than the average class, and this tends to limit reusability. I would say that they work best in a situation where they are fairly strongly associated with a single Access application. While you can go through a couple of hoops and create a class that is reusable by other applications, the result carries a relatively huge footprint. If you want to create a component that is used by multiple applications, consider creating an ActiveX DLL, using a development tool such as VB6.
HTH
Bob
