The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I'm a sole developer, so the team aspect doesn't affect me.
But...I mostly use separate assemblies rather than folders within a single assembly, mostly for separation and reuse reasons. I just find that it makes it easier to "black box" a class or layer if it's "physically" separated in a different assembly as I have to think "what else will that affect?" when I make a change - there's a reluctance to change an assembly for a specific task unless it's justified by the possible uses in others. That means that when I do change an assembly the additions are more generic than they probably would have been in a single block, simply because I may want to use the additional feature in other systems later.
I generally don't use separate folders except for resources (where I like to separate text, images, control images (such as button "skins"), and such like from each other).
Not sure if that makes any sense, but it's the way I work!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I'm working with a suite of tools, all sharing a common framework. I tend to split things up into assemblies based on their general use... One assembly for market data interfaces, one for product valuation, one for my data access layer, etc.
The advantage is that different projects only pull in the assemblies they need, so when I'm making a change, it's easier to see the potential downstream effects. If I'm modifying my "Base" assembly (Pretty much the hub of the entire framework), I know to be a LOT more careful not to make any breaking changes. If I'm working on an assembly that's only used by one non-critical application, I can save time and play it a bit looser (RAD environment, so patches can be released in minutes instead of days).
Technically I could do the same thing with namespaces, but it's a lot easier to look at DLL references than to scan an entire project to see which namespaces it touches.
Also, as a side benefit, I make heavy use of 'internal' classes. While various parts of an assembly might interact which each other, I maintain careful control of which parts are actually public. That way I can look at each assembly as black box, and minimize the danger of breaking other parts of the system.
TL;DR;: I use assemblies as another level of encapsulation, to minimize regression issues.
My product uses separate assemblies for a couple purposes. First are tools and utilities used commonly between the three applications in the product.
The second is a little more interesting, in that I use separate assemblies and reflection for a plug-in framework. I have the option of customizing the product by replacing a plug-in assembly if I wish. To some extent this helps me tailor the product at run-time rather than at compile time.
I could do all of this without using separate assemblies. Having purpose-specific assemblies gives you a level of organization above that of source file. While I've seen plenty of code that could benefit from more organization, I've seen very little where the organization was overdone.
I noticed many webby people (at least in my previous company, maybe it's a culture thing, hence different in each company) they were the kind who would would create zillion of library with just 2 or 3 classes each.
They called it "separation of concerns" you see?
I am just glad none of them designed the .NET BCL!!!
As a side note, my preference, I usually put everything with the same dependencies in the same assembly.
I.e. ALL general purpose utilities in one DLL
All utility related to a UI framework (WPF, WebMVC, Xamarin) in another DLL
All reusable business data & model in one assembly
finally all views, viewmodel related to an app in the app itself
Reusability. You can reuse the assemblies in another program without having to import all that code. Better yet, you can easily reuse only part of the code, picking and choosing which assemblies you need.
Had to do exactly the above recently. We were able to leave out the parts of the code that required Windows UI libraries that don't exist on Linux yet through judicious choice of assemblies.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Cross-platform considerations are few and far between. I haven't had to write "cross-platform" code since 1989 using C++, and even then, we abandoned the effort after one application, even though (I thought) it turned out well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 - You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 - When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
I used to be of the camp to have many projects in a solution, thinking of allowing for maximum re-usability of ALL the components, including the following:
Business Logic Types
Data Transfer Object Types
Nowadays I structure my solution based on my designed deployment model. I try to work towards minimizing the number of projects, and currently my model is like the following:
Desktop Application Project
Desktop Application Installer Project
Web Application Project
Web Application Installer Project
Business Logic Public Contracts Project
Business Logic Platform Project(s)
For the business logic public contracts library, this project would contain as much business logic as I can stuff in a platform agnostic manner (in a portable class library, for example). Typically DTOs are placed here, alongside public types that contain re-usable business logic.
The platform-specific projects utilize the public contracts project. These kinds of projects will actually contain the database types, and will translate the DTOs to the underlying platform-specific data types.
Namespaces relates to the logical organisation of the code.
Assemblies relates to deployment, and can be governed by things like a plugin architecture, need for patch updates, versioning, reuse between different applications etc.
That's two different things, just like in UML where you can have both a logical view and a deployment view.
I come at this issue from an SCM viewpoint and while I think there are valid arguments to both separation and collapse, I tend to see many development efforts where the separation was based on how easy Visual Studio makes it. If the developers have discipline, this isn't necessarily a bad thing, but if not, you can quickly get spaghetti code.
I personally believe that all other things being equal, fewer artifacts is better. There are circumstances where they should split, but I default to not creating an extra assembly.
I'd recommend reading the 'White Book' Partitioning code base through .NET assemblies and Visual Studio projects found here: NDepend White Books[^]
The only point of multiple assemblies is if you want to use a part or parts of the projects in another environments. That is using shared libraries the way they've been used for decades now. Another reason would be if you want to run that stuff in a scalable cluster. One assembly does X, mutliple copies of the other assembly do Y and they communicate via some sort of IPC or network.
Outside of creating libraries because I actually need a library and outside of clusters, I always go with folders & namespaces. Because there's no reason to break up a single-responsibility project into multiple binaries. It only makes deployment more complex (albeit not much more) without any benefits.
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
A company I worked for employed a young man called Richard Head (what were his parents thinking?). And another one had a young lady called Annette Curtain. There was also a lady called Ann Winters, we speculated that she sold lingerie to Eskimos.