Say I've got an application that has three layers (presentation, business logic and data tier). The business logic puts the data into custom objects. When it comes to organising the classes of this business layer - so there are 20 of them. Am I best just creating
one businesslayer.dll, or should I group them into functions and create a dll for each class grouping (books, authors, etc). I only day this because the classes will be of use to other applications - but only a subset of all the business logic classes - so
splitting them up means I need only use the ones I need in each app rather than using the full business logic layer each time. Or I'm talking rubbish :)
If the classes are _really_ going to be of use in other applications, then it's worth splitting them out into a separate assembly. Otherwise, I don't see any particular reason to split the business layer assembly as you describe it. I'm not sure of the classes
you have of course - maybe they're vast! - but 20 classes isn't really that many. Hope this helps,
::Or I'm talking rubbish :) No, you are not. I do something similar here. I split my busines logic along "functional groups" (user management, for example - accounting), mostly along namespaces. At one point it is just easier to compile only parts, test only
parts and - reuse parts.
Ian O'Rourke
Participant
1835 Points
367 Posts
One DLL or Many
Feb 02, 2004 09:48 AM|LINK
MishMash
Member
330 Points
66 Posts
Re: One DLL or Many
Feb 02, 2004 11:37 AM|LINK
thona
Member
20 Points
2923 Posts
Re: One DLL or Many
Feb 02, 2004 11:55 AM|LINK
Ian O'Rourke
Participant
1835 Points
367 Posts
Re: One DLL or Many
Feb 02, 2004 12:03 PM|LINK