Folders and Namespaces vs Multiple Assemblies
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013Used carefully,
internal(Friend) classes, methods and so on can be a useful tool for controlling who uses what and that capability is lost to you if you have everything lumped into one large assembly. -
Used carefully,
internal(Friend) classes, methods and so on can be a useful tool for controlling who uses what and that capability is lost to you if you have everything lumped into one large assembly.I think this is more of a code organization discussion rather than one of accessibility.
".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 think this is more of a code organization discussion rather than one of accessibility.
".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, 2013In that case, so long as each project compiles to its own assembly, there is no problem I can see having all the projects in one solution in a subfolder per assembly basis.
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013It depends what you're doing really. A stand alone application/library might be fine in a single assembly, but a solution may have multiple projects, a desktop app, a web app etc. that share the same common components [data access for example]. In which case it's easier if everything is separate and updates to individual components can be released without having to reinstall whole applications.
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013N-tier architecture? duh. Presentation layer (desktop,web, mobile, etc.) Business layer Data layer Domain - models project. etc.... WCF services Web API blah, blah, blah :-D
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013I have the same experience as well, developers advocating multiple assemblies, mostly "just because". I haven't really heard a compelling argument. Separation of concern should be done at class level, and beyond that separate assemblies rarely (if ever) add anything to it. On the other hand I had to deal with multiple issues because of this. One client had a solution so split up, when built it would take up 1 GB of disk space because projects referenced other projects, and every time the dlls would get copied to the output directory, some dlls duplicated 20+ times. And if this does not sound bad enough, it wasn't some huge back-end transactional processing whatever system. It was a web site with around 25 pages (I wish I was exaggerating). Second issue I've noticed that it's a nightmare for dealing with circular references, because there will always be at least 1 instance of this happening, and the more dlls the more likely. One company solved this by making every dll a NuGet package as well. It was a PITA to build, as you had to build project A, publish it to the feed, update for project B and then build that. But hey, at least no one had to do care where to put what... Obviously not saying multiple assemblies are a bad thing per se, but in my experience they are used lot more then they should be.
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013Only Organizational? - sure... hmm.... I don't agree... I do it for technical reasons. The most important: Management of dependecies for a specific project. If I need a driver lib in a project I will add the reference there - so it's clear which code parts depend on what(3rd Party) libs. If I'd add all the references to one project you won't know which code depends on what. So it's much easier to create selfcontained reusable parts with only the needed dependencies. There are ohter technical reasons too... e.g sometimes (for me mostly when working with WPF) I have to split up the Code to different assemblies to "Support" the VS designer. (Better dont try to create and use MarkupExtension in the same assembly..., same with (themed) resources, UserControls etc.) Then sometimes for differnt reuse strategies/contract only assemblies - e.g some things are defined PLCs (PortableClassLibraries) like contracts for WCF while implementations are not PCLs. Now if I think about it, I could come up with a lot more advantages like compile times when not doing a complete rebuild... I wonder why you stated that MS intended it to use folder structures instead of more assemblies (which would contradict the name they choose)
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013Separated 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.
-
I have the same experience as well, developers advocating multiple assemblies, mostly "just because". I haven't really heard a compelling argument. Separation of concern should be done at class level, and beyond that separate assemblies rarely (if ever) add anything to it. On the other hand I had to deal with multiple issues because of this. One client had a solution so split up, when built it would take up 1 GB of disk space because projects referenced other projects, and every time the dlls would get copied to the output directory, some dlls duplicated 20+ times. And if this does not sound bad enough, it wasn't some huge back-end transactional processing whatever system. It was a web site with around 25 pages (I wish I was exaggerating). Second issue I've noticed that it's a nightmare for dealing with circular references, because there will always be at least 1 instance of this happening, and the more dlls the more likely. One company solved this by making every dll a NuGet package as well. It was a PITA to build, as you had to build project A, publish it to the feed, update for project B and then build that. But hey, at least no one had to do care where to put what... Obviously not saying multiple assemblies are a bad thing per se, but in my experience they are used lot more then they should be.
If you have a circular reference that means you're doing something you shouldn't be doing. :rolleyes:
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013q.v. Tab vs Spaces
veni bibi saltavi
-
If you have a circular reference that means you're doing something you shouldn't be doing. :rolleyes:
-
Only Organizational? - sure... hmm.... I don't agree... I do it for technical reasons. The most important: Management of dependecies for a specific project. If I need a driver lib in a project I will add the reference there - so it's clear which code parts depend on what(3rd Party) libs. If I'd add all the references to one project you won't know which code depends on what. So it's much easier to create selfcontained reusable parts with only the needed dependencies. There are ohter technical reasons too... e.g sometimes (for me mostly when working with WPF) I have to split up the Code to different assemblies to "Support" the VS designer. (Better dont try to create and use MarkupExtension in the same assembly..., same with (themed) resources, UserControls etc.) Then sometimes for differnt reuse strategies/contract only assemblies - e.g some things are defined PLCs (PortableClassLibraries) like contracts for WCF while implementations are not PCLs. Now if I think about it, I could come up with a lot more advantages like compile times when not doing a complete rebuild... I wonder why you stated that MS intended it to use folder structures instead of more assemblies (which would contradict the name they choose)
johannesnestler wrote:
There are ohter technical reasons too... e.g sometimes (for me mostly when working with WPF) I have to split up the Code to different assemblies to "Support" the VS designer. (Better dont try to create and use MarkupExtension in the same assembly..., same with (themed) resources, UserControls etc.)
Dontcha wish they'd fix that? I have to deal with that as well. Not only that, but don't get me started on the WPF designer's complete inability to resolve XAML references if the source code is on a network share.
johannesnestler wrote:
I wonder why you stated that MS intended it to use folder structures instead of more assemblies (which would contradict the name they choose)
Because they went completely away from code re-use strategy that exists in native C++ code. You could include a library's source code in a solution without having to actually copy that library's source code to the new solution. I found that quite handy (even though we all know that code re-use in its intended form is pretty much a myth).
".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 -
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013We 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.
"It never ceases to amaze me that a spacecraft launched in 1977 can be fixed remotely from Earth." ― Brian Cox
-
johannesnestler wrote:
There are ohter technical reasons too... e.g sometimes (for me mostly when working with WPF) I have to split up the Code to different assemblies to "Support" the VS designer. (Better dont try to create and use MarkupExtension in the same assembly..., same with (themed) resources, UserControls etc.)
Dontcha wish they'd fix that? I have to deal with that as well. Not only that, but don't get me started on the WPF designer's complete inability to resolve XAML references if the source code is on a network share.
johannesnestler wrote:
I wonder why you stated that MS intended it to use folder structures instead of more assemblies (which would contradict the name they choose)
Because they went completely away from code re-use strategy that exists in native C++ code. You could include a library's source code in a solution without having to actually copy that library's source code to the new solution. I found that quite handy (even though we all know that code re-use in its intended form is pretty much a myth).
".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, 2013John Simmons / outlaw programmer wrote:
code re-use
In theory you should be using pre-compiled assemblies that perform certain logical tasks - printing, file storage, uploading, etc.... The term "code re-use" started off as a business side term, IIRC - because most business people don't know any better. If you are copying actual code from one solution/project to another (repeatedly), then you are probably doing something wrong (i.e. put it in its own assembly and re-use that), unless you are working in the WPF world, etc.
-
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.
:thumbsup:
-
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 -
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, 2013Didn'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.
-
John Simmons / outlaw programmer wrote:
code re-use
In theory you should be using pre-compiled assemblies that perform certain logical tasks - printing, file storage, uploading, etc.... The term "code re-use" started off as a business side term, IIRC - because most business people don't know any better. If you are copying actual code from one solution/project to another (repeatedly), then you are probably doing something wrong (i.e. put it in its own assembly and re-use that), unless you are working in the WPF world, etc.
Slacker007 wrote:
you are copying actual code from one solution/project to another (repeatedly), then you are probably doing something wrong (i.e. put it in its own assembly and re-use that),
I don't think you understand the differences of which I speak. IN Native C++ solutions, you can actually include external libraries' SOURCE CODE in your new solution, and make changes to it there (ostensibly without breaking other stuff already in use by orther solutions). In .Net solutions, that isn't possible without either opening up the library's project in another instance of Visual Studio, or copying that assembly's code to the new solution. This isn't NEARLY as convenient.
Slacker007 wrote:
unless you are working in the WPF world, etc.
Bingo.
".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 -
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013Long 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
-
This discussion came up at work today, with pretty much everyone falling on the side of using multiple assemblies, but with no viable reason for doing it that way, and most of the time saying, "because I've always done it that way". Beyond utility methods or object extensions living in assemblies that could be added as a reference and that could be used throughout other solutions, what's the point of creating multiple assemblies when a thoughtful arrangement of folders in a single-project solution would be perfectly adequate? It even appears as if Microsoft intended for it to be this way. I suppose an argument could be made in a team environment to more clearly separate concerns and ease source control issues, but even that's kinda flimsy at the heart of it.
".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, 2013I 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.
