Object Orientated Design Question | Tech Off

risu

Hello All,

First if any one knows of any good books that really dig in to questions like the one I'm about to ask or blogs/columns that deal with (specifically .NET) project and solution design I would greatly appreciate the point in the right direction.

That said, here we go.

For common objects that will be used across a large project by many different developers is it better arrange everything so that there is one .dll or many specific .dll's?

Say we have 10 commonly/occaisionally used objects (A-J) that will be accessed across the program. I can do anywhere from one to 10 .dlls, What would you do?

Is it more of a performance hit (if even one at all) to load a large a .dll just for one class or to load 8 of the ten individually?

I'm basically looking for any comments that the C9 crowd may have to share and I understand that there is most likely not a definite answer. However if I could just listen to the opinions posted and read any sites/books suggested I'll be a little better prepared to make my choice.

Thanks,
Risu

Blkbam
Bam, Bam! Bam, Bam Bam!

risu wrote:

For common objects that will be used across a large project by many different developers is it better arrange everything so that there is one .dll or many specific .dll's?

Say we have 10 commonly/occaisionally used objects (A-J) that will be accessed across the program. I can do anywhere from one to 10 .dlls, What would you do?

I don't know about a performance hit but I can tell you from experience at my company, we have over 50 dll's we ship with our product. Try supporting that as a developer. Do the programmers a favor and group anything that's similar together. They'll thank you later.

Charles
Welcome Change

Without knowing exactly what you're doing... In general, it's a good idea to encapsulate related funtionality in a single dll. Certainly, if you've created 10 classes and they will provide some sort of generic utility across applications, then put the classes in a single "general purpose" library.

Charles

object88
amplify.

In a past project, we had two huge DLLs for several dozen objects. I was responsible for one (VC++ 6), and some other folks for the other (VB6).

On one hand, it would have been nice to have everything in one language and in one DLL. We would have solved a lot of technical problems that way.

On the other hand, some objects got bundled together, which shouldn't have been. In my DLL, there were effectively two layers... one which group A used, and one which group B used. Sometimes there was overlap. It would have made more sence to have that in seperate DLLs.

Hope this helps a little. Assuming no technical language barriers, break it down by close functionality.

dwoodard

While this posting doesn't specifically discuss solution design, it does discuss the performance implications of single assembly vs. multiple assemblies.

http://blogs.msdn.com/junfeng/archive/2004/02/23/78139.aspx

Junfeng Zhang works on the Fusion team and has some good insights.

The bottom line is one assembly is better from a performance perspective than multiple. However there are other benefits of multiple assemblies such as increased modularity and extensibility to name a few.

-dan

risu

Thanks All for the comments.

I appreciate the help lots. I currently do have all of my common objects located in one dll. Based on dwoodard's link I'll see if I should change that.

Being a relatively new programmer I've seen my style change in the year I've been working on this project. This is whats bringing about my question.

Current phase is a user control that will track incoming materials for use in our products. I have 3 dlls coming out of the Solution. One for the control itself, one for objects that are very specific to the control and functionality and one dll (forms) for sub forms and dialogs.

As opposed to an earlier phase where I wrote a product routing form and everything (main form, sub-forms, objects, print object) was thrown together in one big dll.

This is where my problem comes in. one of my user control sub-forms has to call the print object from the routing form. Now the routing dll is not insanely huge ( 3MB ) but I'm wondering if it's worth the effort it would take to seperate out functionality. I'm sure I would also have to then justify it. However if it was considered a good design principle to have such functionality seperated out then I would change it even if I had to do it on my own time.

I'm pretty confident that I should just go ahead with it as is but I'm trying hard to make sure I learn good and effective design principles so I thought I'd ask what everyone here thought.

I appreciate the responses that I got and hope that i can gleam some more insights from everyone.

Thanks,
Risu

PS I did have a design spec for the routing form project but all it said was "Routing form -- allow users to build rotuings for each product using other routings as a base"