1 dll or multiple dlls?

[carriemjohnson]

I'm developing in an application that has gotten fairly large. We currently use 1 dll to do several of our processes. But are looking to expand our functionality using the same dll tools. My question is - is it better to use 1 dll (even though it's going to be quite large) or is it better to split the information into multiple dlls?

 

[footpad]

carriemjohnson,

It really depends on the contents of the DLL, the scope of your planned changes, and the amount of work it would take to design, build, and test a multi-DLL setup.

Multiple DLL's (or packages, for that matter) can reduce duplicated effort and are very useful for refactoring, however they also can also create more deployment, integration, and development headaches.

I've always advocated well designed support systems, but I think you may also wish to consider whether or not the number of changes you want to make are worth the additional effort at this time. Much depends on the project, it's budget, and other future changes you have planned.

If you can make a good case for the increased development time, then I suspect the extra work will pay off in the long run. On the other hand, if your clinet(s), manager(s), and/or project sponsor(s) are expecting simple (and quick) changes, they may need to be convinced to support the extra effort.

Kind of wishy-washy I know, but that's about the best advice I can offer at the moment.

Hope it helps...

-- Lance

 

[carriemjohnson]

I've been trying to weigh the positives and negatives of doing multiple dlls, so you're information really helps. Could you tell me what kind of "deployment, integration, and development headaches" I could expect? I apologize I don't know as much about all of this as I would like to.

 

[footpad]

carriemjohnson,

Well, from a practical standpoint, each DLL is a separate project. You may have run into issues working with your client project and the one that builds you existing DLL.

Project Groups can help with some of the proeblems with making sure that all projects are rebuilt at the same time and so on, but you have to make sure that the Group is designed well and that each separate project is set up appropriately. It takes a little getting used to, but works well when done properly.

Some of the issues I've run into in similar situations may or may not apply to yours, so take these with a grain of salt:

1. If you use an Installation program to deply things to your end users (e.g. InstallShield and WISE), you need to make certain that each of your projects dumps their results into the location the install script expects them.

2. If you plan to offer online updates, you need to make certain you build enough information into the process to be able to accurately determine whether or not a certain DLL needs to be replaced.

3. If you intend to update on the fly, you need to verify that the DLL isn't in memory when you try to replace it; otherwise, Windows will block your attempts to replace the file.

4. If you intend to share resources between the projects, you need to add mechanisms for passing appropriate handles and pointers.

5. If you change the interface of a DLL, you need to verify that each other DLL/EXE that uses that interface is also properly updated (though this can be somewhat handled through good use of Interfaces.)

6. If you're sharing external files, such as tables, text files, and so on, you need to make sure that each "client" properly verifies the file can actually be accessed before trying to write to it. If you're a careful programmer, this shouldn't be too much trouble, but I've seen many cases where careless programming falls apart in a shared environment--and it can take a lot of effort to trace down the reason for the failures.

7. When working with separate projects, there's a great temptation to duplicate code, rather than share it appropriately. Resist this at all costs. As Murphy has demonstrated more than once, you will eventually run into a situation where one copy of the code gets updated in one DLL, but the other is accidentally forgotten.

8. Another installation problem comes when you install over previous versions. You need to make certain that all updated files are properly replaced. Otherwise, you'll get plenty of strange and non-reproducible bug reports from the field.

None of these are fatal and all of them can be avoided through careful--and consistent design. However, unless you have a team that can afford someone to verify that everything's as it should be, it can be very hard to apply the best technqiues at all times, especially when you have angry users/managers breathing down your neck due to a silly bug.

There's a book I highly recommend that will help you avoid the silliest of mistakes. Specifically, The Pragmatic Programmer, by Andrew Hunt and David Thomas. (Its web site is at

http://pragmaticprogrammer.com/

and there's one review at

http://perlmonks.com/index.pl?node_id=76219).

I personally found it helpful in learning to think in ways designed to avoid silly mistakes, like the ones that lead to hassles with multiple DLL's.

Note sure if this answers your question, but I still hope it helps...

-- Lance