Best Practise: Many Small or viewer Large assemblies

[Guest]

When one architects a new project one of the first steps in the decision is
to decide on the layers. (In my opinion anyway)

One architecture that I have used before is to go solid OO and create
objects, which normally are very small and only deals with the stuff
pertaining to that object, then break it down into Business Process, Process
Controllers and Data Access Objects for each "Object", each of which is
created in it's very own .Net project and becomes a completely separate
assembly (Dll). The thing is that the assemblies are often very small.

Another way is to dump all the Business components for an entire application
together into a single assembly. Doing the same for the DAL and the BPC's
essentially creating only a few larger assemblies.

Personally I like the first option, since I don't have to load this monster
assembly into memory to start only one class and execute one or two small
methods. Also, it makes more logical sense (to me anyway) and is therefore
more manageable.

One problem with this though is that on large applications you could end up
with hundreds of projects in a single solution, but that can easily be
overcome as we all know by just creating smaller work specific solutions.

What would be the Best Practise kind of answer to this?

Thanks
David

 

[SUNILR]

I think it best option is based on case to case basis. In my opinion,
if project is larger and team size is biger then first option suite
where well. Since number of people can work at simultaneously. If the
team size is less and project is also small and less reusability then
few assemblies opens suite were well.

Sunil Raskar (MCSD)

 

[SUNILR]

When one architects a new project one of the first steps in the decision is
to decide on the layers. (In my opinion anyway)

One architecture that I have used before is to go solid OO and create
objects, which normally are very small and only deals with the stuff
pertaining to that object, then break it down into Business Process, Process
Controllers and Data Access Objects for each "Object", each of which is
created in it's very own .Net project and becomes a completely separate
assembly (Dll). The thing is that the assemblies are often very small.

Another way is to dump all the Business components for an entire application
together into a single assembly. Doing the same for the DAL and the BPC's
essentially creating only a few larger assemblies.

Personally I like the first option, since I don't have to load this monster
assembly into memory to start only one class and execute one or two small
methods. Also, it makes more logical sense (to me anyway) and is therefore
more manageable.

One problem with this though is that on large applications you could end up
with hundreds of projects in a single solution, but that can easily be
overcome as we all know by just creating smaller work specific solutions.

What would be the Best Practise kind of answer to this?

Thanks
David

 

[Guest]

Thanks for the response...

Bear in mind though that my question is not so much about people being able
to work simultaneously on a project. This can still be achieved if the large
assemblies contain several classes (In separate cs files) each.

My question is more about performance. I heard somewhere that smaller
assemblies may cause "Memory fragmentation". Is this true? And what is the
impact?

In a high performance application where many thousands of instances of a
class could be started, I can not imagine it being that great to have these
large assemblies each taking up a major chunk of memory for the application
to only use very little functionality in each.

If only a single class is instantiated in a “large†assembly containing many
other classes (that in this instance will not be used), surely the OS must
load the entire assembly (or dll) into memory, wasting the space required for
all the other classes that will not be used.

As for memory fragmentation, if the application is running many instances of
a small class, surely the assemblies/class will be pooled and thus not be
unloaded from memory every time and therefore not cause memory fragmentation.

Have I just answered my own question? When the application is expected to
deal with very high usage, with many hundreds and/or thousands of "users"
using the application, and pooling is enabled/possible, the assemblies should
be small, while for a large application that will deal with one transaction
every 60 seconds, you might as well, load large assemblies, since the smaller
one's will not be pooled anyway, since they are only used once in a while and
it may exceed there lifetime, so they will be loaded, and unloaded and
reloaded, and therefore may cause memory fragmentation???!!???

Any other references, suggestions, questions, comments and/or concerns would
be most appreciated.

Thanks
David

 

[Goran Sliskovic]

When one architects a new project one of the first steps in the decision is
to decide on the layers. (In my opinion anyway) ....
What would be the Best Practise kind of answer to this?

....
"The granule of reuse is the granule of release".

This may be helpfull:
http://ifacethoughts.net/2006/04/04/reuserelease-equivalency-principle/

Regards,
Goran