Back in the day, when VB was king, there was a simple model for the creation of an app's components: a single monolithic exe containing all of an app's logic. Sure, you might be using an n-tier model, and perhaps your back-end logic consisted of several components; but that UI was just one big file.
Even now, there are people around who still advocate this approach (such as
Gavin, who I mentioned in a
previous post). These folks prefer it this way because it's the way it's always been for them. When they load up a solution containing multiple projects, they take offense.
Let's clear one thing up first: a single monolithic assembly will perform better than several assemblies. There's an overhead in locating, loading, and initializing each assembly, so if you have just one it's obviously going to be faster. Yet, by the same token, if you ditch the n-tier model and lump everything onto a single server (i.e. the way mainframes work) you could also improve your performance by removing network latency (obviously, under load, this model won't work unless you have serious hardware). Another thing: on the client, where there's just a single user, the overhead of loading an assembly is pretty much nil.
Thing is, performance isn't the reason folks
blench at the many assembly approach; it's simply because they're not used to it, and find it tricky navigating around the code; oh, and it takes Visual Studio longer to load the more projects you have in your solution. It's too much of a culture shock... so let's just have one project with everything in it. Better still, why not just shove all your logic behind the events in each form; why have multiple classes or methods when you can just have masses of code behind your event handling methods?
The approach I take is:
- Develop reusable components; if certain custom controls are generic and can be used in other apps, put them in a separate assembly - you can't reuse them if they're embedded in an exe; similarly, if your app uses encryption then it makes sense to put encryption code (or even all code that relates to security) into a separate assembly, and so on; components should be small and specialised i.e. they do one thing and they do that one thing well;
- Use object oriented principles; split your component into small, highly specialised classes - don't be tempted to just have a single class (who would do this?), or vaguely specified classes whose names end in Helper, or Utilities that contain unrelated flotsam and jetsam (i.e. don't treat classes as just things you put methods in - they are entities); like you, a class must have purpose in order to exist;
- Methods should also be small and highly specialised; never put anything more than calls to methods into event handlers behind controls in forms; methods should never get very large if they only serve one specific purpose; write one thing once only, and reuse it (i.e. never duplicate logic, as it makes your code impossible to maintain and introduces bugs); you'll also find your code starts to become more readable - a small, specialised method will have a very specific name, making it immediately obvious what it does;
If you do this, you'll be amazed at how reusable your code becomes, from the method level up to the component level.
