I was wondering what is the best and most maintainable way to seperate your dll's?
I am building a WinForms application that makes use of Classes I want to re-use in other applications. So here's the catch:
Let's say I build a library called StringManipulator, put it in a seperate project file and build it as a dll. Pretty obvious what it does. Now I want a user interface that calls my StringManipulator.dll. For this user control I am making a new project, called StringManipulator.WinForms.dll. I do this because at a later time I might need the StringManipulator in a WPF application.
So it's a little like this:
StringManipulator.WinForms.dll needs StringManipulator.dll
So I now have two dll's, not so bad. But as the application progresses I have MANY dll's, all consisting of a general part and a WinForms specific part. Many dll's have only one or two classes and it all becomes quite hard to maintain (should new code go in an existing dll or in yet another new dll?). Plus a single application could actually reference all twenty dll's, which seems like a lot to me...
Things now look more like:
Project1.WinForms.dll needs Project1.dll
Project2.WinForms.dll needs Project2.dll
...
Project10.WinForms.dll needs Project10.dll
That already makes twenty dll's for ten uses!
So to make things easier I put all WinForm controls in a single dll. Wrong! My WinForm dll now references about 10 other dll's. Now when an application needs one WinForm component I need to deploy ALL my dll's even if I needed just one control.
It looks like this:
WinFormsProject.dll needs Project1.dll, Project2.dll ... Project 10.dll
Now surely I am not the only one with this problem. I've read about dll granulation (
these articles by Robert Martin no less![
^]), but I've also seen posts on the internet where companies had 50 dll's and where building, maintaing and deployment became a nightmare.
Currently I am in a situation where one dll references many which in turn reference other dll's too. Now a colleague wanted to use a single control from the WinForms dll and as a result had to deploy ALL dll's (about twenty) that he doesn't use at all (now actually this just means copying a folder full of dll's to the customer).
Now I am pretty much in favour of having many dll's even if they have only one or two Classes each. Of course we'd still have to deploy lots of dll's, but at least they would all be used. Another alternative would be to just throw it all in one big project file since we now have to deploy everything anyway.
At the current stage of development I could relatively easy break up the WinForms component into many small components. In the future we will be implementing our dll's into more applications and segregating further will become more difficult.
I'd like to hear the opinions and experiences of the people here. What do you suggest and recommend? Any tips if we choose one way or another?
Thanks.