Can you have too many assemblies in an application?

[n33470]

Is there any guidance, or best practice, with respect to deciding how
to package classes into assemblies? I guess what I'm wondering is if
anyone has noticed a difference in application performance when the
same application is packaged between fewer large assemblies (with many
classes in each assembly) versus using more smaller assemblies (with
few classes in each assembly).

Is it possible to have an application that references too many
assemblies so that the performance of the app suffers? Is there any
guidance on deciding when to create a new assembly, versus keeping all
the code together?

Thanks!

--steve

 

[Anders Norås [MCAD]]

Is there any guidance, or best practice, with respect to deciding how

to package classes into assemblies? I guess what I'm wondering is if
anyone has noticed a difference in application performance when the
same application is packaged between fewer large assemblies (with many
classes in each assembly) versus using more smaller assemblies (with
few classes in each assembly).

Loading many assemblies is slower than loading few assemblies. However,
under normal circumstances the performance impact of loading more assemblies
is insignificant.
Concerning guidelines you should only reference assemblies you actually use
and design classes so that the classes don't expose their referenced
assemblies so that related assemblies don't have to be referenced.

Is it possible to have an application that references too many
assemblies so that the performance of the app suffers? Is there any
guidance on deciding when to create a new assembly, versus keeping all
the code together?

I can't recall ever reading or hearing a maximum number of referencable
assemblies, but there is a limit. However, the memory of the computer
running the application is likely to run out way before you reach this
limit.
Try to package assemblies so that the classes within the assembly so that
they are logically grouped.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

 

[Nick Malik [Microsoft]]

just to add to Anders' response,

Cohesion among layers is a more important consideration than the number of
classes in an assembly.

I would suggest that you are better served by creating a small number of
assemblies for each layer. ( I usually have one or two DLLs for the user
interface layer, one for the data access layer, and less than five for the
business logic layer). For each assembly, write down the purpose in big
bold letters on a sign and hang it on your wall, so you can evaluate each
class and put it into an appropriate assembly. Draw a diagram showing how
the assemblies will reference one another (according to that published
purpose), and make sure that you can actually still do it when you add the
classes to it.

If there is a single class in an assembly that causes you problems (e.g. it
needs a reference to code in another class that would cause a circular
reference, don't just automatically move the class. Look at it. Does it
need to be refactored (rewritten to improve structure)? Is there a pattern
that you should be using that you didn't consider before?

This is why we create layers... to force us to think about how we partition
our logic, and how we build classes to support that partitioning.

Hope this helps,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[n33470]

Nick/Anders,

I think you got side-tracked a little bit. I was not asking about how
to architect with respect to layering. I'm considering different
techniques for packaging the classes within the layers into assemblies.


Within the layers, suppose we're talking about the business logic and
data access layer and you are designing a suite of applications that
will all make use of that business logic design. You may end up with
2-3 windows apps and maybe a website and some webservices. I'd like
to package the business logic into multiple assemblies so that the
logic can more easily be re-used across all the applications.

Consider this....the business logic (BL) and data access (DA) tiers
support the following functional areas Accounting, Shipping, and
Customers. These functional areas are vertical and do not need to
reference each other. I can see a couple of different strategies for
packaging this design.
1. Put all code, BL and DA classes in 1 assembly (1 assembly total)
2. Use 1 assembly for all BL classes and 1 assembly for all DA
classes (2 assemblies total)
3. Use 3 separate assemblies to group functional areas within each
layer, (6 assemblies total)
4. Group the BL and DA classes for each functional area into the
same assembly (3 assemblies total)
Which design would you choose and why?

Thanks!

--steve

 

[Nick Malik [Microsoft]]

Hi Steve,

I'm not sure we were so far off. To summarize my previous posting: Cohesion
is the reason to package things within an assembly.

Of your choices, I'd go with #3. If each assembly has a responsibility, and
it is independent of the responsibilities of other assemblies, then you
minimize the need to modify more than one assembly at a time when your
business rules change. If you've done your unit tests correctly, then you
have confidence that the unaltered code will work with the changes. This
reduces your dev/test cycle and speeds up your delivery, while still
maintaining a high bar of quality.

and that lowers cost.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[n33470]

Hey Nick,

Thanks for the confirmation to the design decision. We've been using
that design of creating cohesive assemblies within a layered
architecture for a number of years. However, our suite of
applications has grown, and the number of cohesive units has grown,
through refactoring, so that the number of local assemblies in our
desktop apps (winform apps) is around 30 assemblies.


My initial question was simply trying to understand if it's uncommon,
and maybe not practical or efficient, for an application to be designed
with many assemblies like this?
Curious what your thoughts are...

--steve

 

[Nick Malik [Microsoft]]

My personal take is that it is neither "good" nor "bad". Your users
probably aren't inspecting the install directory, and if they are, it
probably doesn't bother them. It certainly has a minimal impact on your app
or its performance.

The only time this is an issue is if you have to register a large number of
assemblies in the GAC. Because the GAC is a single flat list of assemblies,
and the tools for looking in there aren't particular smart, it can get
"cluttered". My impression of what "cluttered" looks like is not
meaningful... That's just a personal preference.

On one of my projects, where the GAC is an issue (due to Sharepoint), we
have a single assembly with multiple subdirectories. Each subdirectory
contains a cohesive set of classes. This allows the code review to treat
each one as though it were an assembly, but we end up with a single DLL.
This is not better, because I like the fact that each dll has to declare
it's dependencies. This helps to highlight any circular references that
would indicate a flaw in either packaging or design. We lose this when we
put all the classes in one assembly. It's a tradeoff.

So my preference is to keep things just the way you have them. I've shipped
an app with well on 30 assemblies before, so I know that it "feels"
unweildly at times. I wouldn't be worried about it.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.