DLL vs Class

jccorner

Centurion
Joined
Jan 31, 2004
Messages
144
In my projects, I currently have a class that handles all my database connections and I copy that class into new projects as they are built. Someone suggested I move my methods into a dll project and use that instead. But I was concerned about speed and things of that nature. Can someone let me know which is better?? Greatly appreciate the insight.
 
There are a couple of considerations here.

I like to distribute applications as a single .exe file to keep things simple. I have a "common" project with useful classes. While it does build to a DLL, I typically add individual code files from it to other projects as "links" (this means that the project doesn't keep a local copy of the code file, just a reference to the code file). This allows me to maintain my common classes easily and build them directly into the executables they are used in. This method has its drawbacks, though. Changing the common file in one projects changes it in all projects, which has a potential for disaster. (If I need to make breaking changes, I make a local copy for the one project that needs the changes.) Another problem occurs if the code needs to be shared, since the project will only open and build properly on machines with the common files in the same relative paths, which is very unlikely.

Building a separate DLL has its advantages, too. A DLL update can be issued without redistributing the entire program, and allows multiple DLL versions to be easily maintained side-by-side.

It really depends on what your needs are.
 
Performance shouldn't be a factor. Each dll needed by the app gets loaded at run-time into the same Application Domain.

Seperating common code into a seperate assembly sounds like a good idea in general. The general rule of design I would use in a situation like this would be, seperate what changes from what doesn't.

If the data access code that you wrote isn't going to change from app to app, put it in a seperate dll, it allows the code to be reused effectively.

In most applications I've worked with, we seperate the app into a ui layer, business logic layer and data access layer. What you seem to be talking about is the data access layer, and it is a very common scenario to put the code into a seperate assembly.
 
Back
Top