|
Long response. Short answer: re-usability, modularity, separation of concerns, work through interfaces and pub-sub calls as opposed to direct instance-method calls.
As you said, one reason I keep functionally distinct code in separate assemblies is because of re-use -- I have a library of code pieces that live in separate assemblies so that I can pull in what I need. This is how I've done things:
Core - all the stuff I almost always use:
assertions
extension methods
model-table management
module management
pub-sub
service management
state management
workflow
Then, because I use runtime loading of modules that an application needs, these are broken out into separate assemblies as services:
AppConfigService
ConsoleLoggerService
ConsoleCriticalExceptionService
DatabaseService
PubSubService
PaperTrailAppLoggerService
EmailExceptionLoggerService
EmailService
MessageBoxLoggerService
For web development, there's additional service assemblies:
FileResponseService
WebResponseService
WebRouterService
WebServerService
WebSessionService
WebSocketService
WebWorkflowService
and finally, for application specific stuff, I typically write various components as services (assemblies), so for example, for the ATM/Kiosk applications, I have assemblies that handle:
ATM specific API's
Card swipers
Pinpad API's
Drivers License scanners / PDF417 readers
Receipt printers
Voucher printing
etc.
The real power of having separate assemblies comes to play then, when, for example, I can replace a particular service with a different hardware implementation, or even an assembly that mocks the hardware. So, for example, when I write the ATM software, I don't have a 200lb ATM sitting in my office, I instead use the services for a small Magtek card reader and either an Ingenico or Verifone pinpad, depending on what I'm testing. The interfaces are consistent, so the core ATM software doesn't know or care what the underlying implementation is.
So basically, I find separate assemblies really useful, not just for code reuse, but also for creating a modular system. By asking the service manager what services are loaded, the "system" (either the back-end server or, in the case of a CefSharp hosted app, the Javascript, I can tell others what services are available. And speaking of the CefSharp hosted app, the cool thing there is that the services, as assemblies, are the same whether it's a hosted web app talking through the hardware abstraction layer or it's a WinForm app.
The other thing I do is use a pub-sub system (all that semantic stuff I was writing about a while back) so that, instead of needing to instantiate a class and talk to it, I just publish a message. How that message gets processed (or even if it gets processed) is determined by the services that are loaded at runtime, which of course are assemblies.
I always imagine that scene where HAL 9000 gets deactivated[^], as the architecture I use, whether writing WinForm or web apps, is a bit like that, I can plug in new functionality, or degrade the system, but it still keeps working as best it can.
Marc
|
|
|
|
|
I prefer multiple compilation units, but all the code in one directory, and make files that specify what to build and how.
All this separation into multiple directories causes confusion, accidental duplication, and bugs that are difficult to track down.
|
|
|
|
|
To add to what is being said.
It will depend on the project for me.
If the project is a simple utility then I will use folders within the project.
If the project may have different UI depending on the user I will use assemblies to house the logic layer etc to allow for re-usability
I also like to keep an ever growing assembly of custom routines / objects that I feel I could re-use with other projects.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
I remember one idiotic "Microsoft Field Engineer" recommends to publish all your assemblies to Nuget. I was this close to insult him since all of our assemblies are not public.
|
|
|
|
|
Errm, you can self host NuGet so it is a perfectly valid suggestion. For internal deployment of referenced assemblies, NuGet isn't a bad solution.
This space for rent
|
|
|
|
|
It's not for us. We don't want to put our library for public usage. It remains in our org. That's makes it idiot.
|
|
|
|
|
um, the point was, you can make your own PRIVATE nuget repository located on your own server. But whatever...
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Nailed it. Was waiting @Pete-OHanlon response this way!
Wonde Tadesse
|
|
|
|
|
Funnily enough, I was just posting.
This space for rent
|
|
|
|
|
Wonde Tadesse
|
|
|
|
|
Stephen Gonzalez wrote: We don't want to put our library for public usage
That's why I said self-host. You don't have to make it public - if you host it yourself, you can keep it internal. So, perhaps you're being harsh about them calling them idiot. After all, it's not their fault you don't know about how your organisation can host NuGet internally.
This space for rent
|
|
|
|
|
It wasn't clear like "MFE" guy.
|
|
|
|
|
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.
|
|
|
|
|
Here's a very good reason... If you put classes all inside a project, how do you replace just one class?
Put "replaceable" code into their own projects and you get a separate DLL that you can swap out on the fly.
If it's not broken, fix it until it is
|
|
|
|
|
What prevent you to replace the big DLL as well with a new version of it where just one class changed?
Your "use case" need.... some elaboration...
|
|
|
|
|
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.
Software Zen: delete this;
|
|
|
|
|
it's a matter of taste..
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
|
|
|
|
|
Because "utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions" should be the vast majority of your code.
Your data layer should be in a separate assembly because you'll be using it in the public facing website and on your intranet admin tool.
Your business logic should be in a separate assembly, because you'll be using it on the website, the desktop app, the command-line tool, and the mobile app.
Truth,
James
|
|
|
|
|
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:
- Entity Types
- Repository Types
- Business Logic Types
- Data Transfer Object Types
- Web Application(s)
- Desktop Application(s)
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.
|
|
|
|
|
At some point, the set of folders or namespaces cries out (to me) for its own DLL ... as when I'm dealing with unique hardware devices or third-party APIs.
One also cannot have circular references with DLLs ... helps with keeping your "subject libraries" pure(r).
(Finally, limits my ability to blow my foot off with a hasty "project-wide" code change).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
