|
Separated assemblies instead of just namespaces is useful to prevent some violations of the separation of concern due to laziness. Even if there are some violations it's a lot easier to spot them by inspecting the references.
A data layer shouldn't have access to the views or the business logic. So there shouldn't be a reference to that assembly. In fact. It's probably not even possible to have such a reference as you'd get a circular dependency (e.g. "data layer" needs "business logic" as a dependency and "business logic" need "data layer" as a dependency. Neither can be built without the other, thus everything throws up.)
The same might be possible for separating things like in MVC and MVVM etc.
|
|
|
|
|
q.v. Tab vs Spaces
veni bibi saltavi
|
|
|
|
|
We are using multiply assemblies (a lot of them) and the reason is deployment... We have a patching system that - initiated by a fix from a developer - can create a update package based on dependencies (and some input from the developer)...After that this update package published on a web site, from where the automated (or sometimes manual) update process can download it to the client's site and run it...
If we would pack all the code into a single assembly the package was far too huge...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
I was in a shop that did that too. I'm not saying one way is always better than another way - it's more likely that one way is more appropriate in a given situation.
".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
|
|
|
|
|
Didn't came to argue or convert...Just told my story...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: Didn't came to argue or convert
We're not arguing - nobody has made defamatory speculations regarding parental heritage, sexual preference, or the possibility of affiliation with the Nazi party.
".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
|
|
|
|
|
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;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
