Should I create DLLs for modularity?

Question

I'm working on creating an app that will parse MSDN articles for meta-information such as the article title and other articles that are in the same collection. This app also has a GUI front-end.

I'm interested in making this program more modular by separating the front-end from the back-end and the back-end into two parts -- one that handles the retrieval and general parsing of an HTML-document and one that does more specific parsing related to MSDN itself. The idea being that this will allow custom UIs to be slapped onto the back-end and allow for the app to be able to parse other sites (perhaps Google search results) just by plugging-in a different DLL.

My understanding is that you would normally create DLLs to share code across different applications. However, in this case, I'm only looking for modularity for this one particular application. Is it still appropriate to create DLLs in this case? Or should I be considering a different option, such as just glomming all of the classes together into a single assembly?

I should note that I'm relatively new to programming, so even if the answer is "no", then this will still be a good exercise for me to learn from. If that's the case, I'd like to know if this exercise should be modified in anyway to make it more appropriate.

Answer 1

I think that your idea of using DLLs in this situation is a good idea. There is no appreciable extra cost in using DLLs (possibly a bit more startup cost at the most). And even if you are currently only planning on using them in this one application, it doesn't hurt to still plan for future changes. There is always a good chance that the DLLs can be used with little or no modification in another application if needed.

In addition, splitting it into separate DLLs for modularity might even help with the design and development process. It makes "sharing" global data more difficult (and that is probably a good thing). If everything is in one monolithic assembly, there may be some tendency to just grab some data from some other place. If that data lives in another assembly, then that potentially bad practice is less likely to happen. It may force the developer into rethinking how to solve issues.

Answer 2

DLLs can help with maintenance of your application. If you have future updates and/or bug fixes, you can update specific DLLs as opposed to the entire application. This will also help reduce your testing surface area.

During development it will also be a bit easier to stub out certain classes/DLLs and swap in the actual DLLs later once developed.

I wouldn't go crazy and put every class in its own DLL. From a high-level there should be a clear grouping of classes that should be together.

Answer 3

There is several advantage to make a DLL:

• the DLL can be changed independently from the caller program (front-end)
• the DLL can be distributed by itself, independently from the caller problem (front-end)
• if several simultaneously running software use the same DLL the memory footprint will be smaller

It also comes with a cost:

• you can't use simple inheritance scheme to extend DLL classes
• sharing global data is still possible but more difficult (some may say this force better design, but it's still a constraint)
• unit testing of code included in a DLL is more difficult
• there are installation issues (the dll must be put in special places and registered, depending how you use it)

But the main point regarding modularity is that DLL is still a half measure. Even if we ignore costs, it is not much better than a lib or even just reusing existing classes. The main advantages are for resellers, not really for software developers, except if you expect third party contributors. And the called functions are still running in the same process that the main program.

If you want a real clean cut for modularity you could use a real multi-tiers architecture with separate processes for front-end and back-end and a communication layer between them (say TCP sockets). That is usually both more versatile and more robust, and not much more complex when done early enough in project life.