Sharing Assemblies

Question

Hi

A have a design question. I have wrote a couple of c# applications. Most of these apps have their own sql or access database, but then they also share a common database, but they are entirely different apps which have their own responsibilities in their own business domains.

Some people I spoke with believe the following : Applications should be silos. They should share nothing. No sharing of assemblies, components or databases.

I need advice on this. When is it acceptable to share, or is it never a good idea.

Thanks

Answer 1

Isn't that a bit the whole point of a "dll" of assambly? To share things...

Why recreate and double-maintain the code when you could share things in an assembly?

Answer 2

You should share everything (within the limits of common sense of course.) You are a team of developers, not a set of individual developers. Sharing code has numerous benefits: reusability means quicker development, simpler maintenance (you only need to fix a bug once), a new feature or improvement is potentially able to benefit all dependent projects immediately and it means sharing ideas as well. Personally, I have learnt a couple of tricks and good practices from the source code written by my coworkers.

Answer 3

The benefits to using dll's to share code, is that you should only have to write the code once. If each application is a silo, then you have to keep multiple copies of the same code and so have to potentially fix the same bug in many places.

However sharing code between apps brings a whole series of problems with it. The instant you share code, you run into problems of different apps wanting different versions of that shared code. This is commonly known as dll hell. Even .NET - with its system of allowing multiple versions of the same dll to coexist on a system - doesn't solve all the problems. Unless you can keep all customers up to date with all products, you will still likely get into the situation of having to make the same change to different versions of the one dll.

There is no right answer on this one. Both silos and sharing bring problems with them.

EDIT:

If you are referring to teams working in silos and not sharing code, then DrJokepu is right: sharing development effort between individuals and teams is a definite "must do".

Answer 4

There is a line, somewhere... sharing library code is positively encouraged - but you need to be a little bit careful when apps consume each-other, simply to prevent spaghetti code and circular references.

If the code you mention is really library code (i.e. neither project is the "master" for this data), then it should be fine (versioning issues aside). If it is the case that Project A wants Project B's data, then it usually isn't long before Project B wants Project A's data, and you have a spider web. In such cases, it may be preferable to use an SOA approach; have the projects expose their data via something like a WCF service, so that other projects only call into the public mex/wsdl API (ideally without assembly sharing).

But it is a deceptively complex question, and I don't think any single answer can cater for every scenario.

Answer 5

Sharing assemblies across applications makes sense only from theoretical point of view. Practically it brings whole bunch of problems. Avoid assembly sharing, deploy all assemblies locally.

Answer 6

I'd say share only what was designed and intended to be shared.

Most times I've found code sharing just out of laziness, that is, sharing code that wasn't designed at all to be shared nor with it in mind. This almost always results on problems later on when the original code needs to be changed and there's no easy way to do it because the code was intended to be used from one location and not several so the designer didn't cope with the possibility of extension for multiple "users".

On the other hand you may have in mind that you are designing something to be shared, for example a communication library or an encryption library or the entire .NET framework. In this cases sharing is ideal and will improve both maintainability and code reuse because the design covered it from the beginning.

That doesn't only applies to assemblies but to classes, resources or any other piece of your project. That's the reason why design is so important, because having thought about it beforehand you have foreseen most of the possible complications and therefore the impact of sharing has been quantified and limited so that the cost of sharing is below the benefits. If you rush into sharing things without taking the consequences into account then your code will not be prepared for it and therefore the cost of adapting the code for sharing or the related problems of sharing will be quite higher than any possible benefit.