Folders and Namespaces vs Multiple Assemblies
-
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.That's what
protectedandprivateare for.#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
-
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:
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.
You can still do that.
#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
-
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
-
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
-
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.
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
-
Nailed it. Was waiting @Pete-OHanlon response this way!
Wonde Tadesse
Funnily enough, I was just posting.
This space for rent
-
Funnily enough, I was just posting.
This space for rent
:)
Wonde Tadesse
-
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, 2013Here'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
-
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, 2013My 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; -
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.
-
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'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!!! :omg: ;P 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
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
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...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
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, 2013Because "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
-
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, 2013Reusability. 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.
-
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 -
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 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.
-
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, 2013Namespaces 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.
-
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, 2013At 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).
-
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 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[^] K.
-
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, 2013The 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.
