when to put classes into different DLL's

[sharkhandler]

Hi all.

I have the following .NET object model:

A series of concrete classes derived from an abstract base class

A factory object that creates and returns instances of these dereived classes

A controller object that creates the factory and processes the objects. This is basically invoked from main().

My question is:

All these objects are currently sitting within a single DLL in .NET. I have logically ordered them into different namespaces but I am trying to work out if they should belong within physically different components. My feeling is that as the factory and derived classes are tightly coupled they should be within one DLL, but the controller object should exist within another DLL, as this could potentially make calls to other factory objects.

Does anyone know the best way of approaching this physical design?

Paul

 

[stefanwagner]

This sounds well to me.
I don't think there is a best way in general.
Putting tightly coupled classes/ objects/ modules in a common dll seems to be a logical starting point.

I don't have enough experiences to give more advices than: make own experiences and than think again about it.

 

[jfrost10]

One way to look at it is to seperate based on PHYSICAL tiers.

For instance, some places have seperate machines to host the business logic and the data access/database. I've seen (and done) where the corresponding code would mimic this set up, whether the actual physical tiers were implemented or not.

With namespaces in .NET, you don't have to worry so much about all your code being within assemblies, since you have a better way to organize them, so I agree that putting all your eggs in one basket isn't a bad thing.

One thing to consider would be, as you already mentioned, if you had code that would interact with other code. For instance, you mentioned your controller object, that feasably could be used in numerous applications. You probably wouldn't want to deploy one assembly that had business logic that wasn't used by another application, so it would make sense to create a seperate assembly and distribute that since it would be generic and not tied directly to any specific assembly.

You're on the right track. As Stefan said, alot of this is just trial and error, and finding what works best for your situation.

D'Arcy