ActiveX DLLs & Modules - Security

Hi,
I'm building an ActiveX DLL and so far i've had everything in a Single class. Now i was thinking of putting stuff like the constants into a standard module, as well as some helper functions...

So Q#1 is this a good idea?? I know its neater n all as far as code goes... but how good is it with respect to security and process contexts??

An ActiveX DLL in VB cannot be multi threaded. So if i have 300 clients for the DLL, true the DLL will load in the context of the Client but will calls to teh constants or helper functions from the module be streamlined or will they be queued??? Is the module another process?? or does the data load in the clients context??

Q#2

Or what if I implement another class will this cause similar issues?? Lets say i aggregate a class that does all my Database access for me... how good will performance be here?? will the aggregted class have requests q'd?? or will it work seamlessly???

Thanks a ton...
Cheers
Gaurav

1. code in a codemodule within a DLL cannot be accessed from outside the dll. So, if you want to use the constants in the program which uses the dll, you need to put them in a classmodule. Depending on what constants it are, it's a good idea or not. I wouldn't put passwords in the dll. (unless you think of a way to expose the constants only after calling an init sub with a password).
A dll isnot multithreaded. An ActiveX exe is though (if you set thread per object in the project properties). An ActiveX exe is slower though then a dll.
But a dll loads in the processspace of the calling program (an ActiveX exe has it's own processspace).

2. In general, the fastest way is to have as less steps as possible. So, using a dll with dataaccess instead of using the recordset directly in your exe is a bit slower, but it can be easier to use and to maintain. Create a testdll, and do what you want to do in both the exe and in the dll, and see what's faster, and how much faster. Sometimes the speed is too important to use it from a dll, sometimes it isn't (for us, speed is not the problem, so we use dll's for the business logic).