|
Linnaeus-type programmers. They split everything up into deeply nested hierarchies of boxes-within-boxes-within-boxes. Not satisfied with the level of "separateness" provided by different class and different files and different namespaces, they will use different projects, and even different repositories.
|
|
|
|
|
*barf*
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Having dozens of DLLs, just to break out the code into bite-sized pieces seems pointless to me - but if there is a "real" need for such then OK.
For example: Prior to .NET I was working on a C++ project that ran data-center automation 24/7 and was not supposed to stop, even for updates.
I designed a system where there was a "stub" program, that didn't change, but all the functionality was spread across several DLLs. These DLLs were real Dynamic Link Libraries in that they were dynamically loaded by the "stub". When some functionality was added, updated or corrected, the appropriate DLL was put in a specific directory and the stub would detect it, unload the old DLL and load in the new one without stopping the main process. With built-in precautions and locks around certain functionality this worked beautifully all the time. Only very rarely did we have to stop and restart the whole thing. Most of the DLLs were eventually actually loaded by other DLLs in a hierarchy and the "core" DLLs were hardly ever updated.
The number of DLLs started at three but eventually grew to, I think, eight or possibly nine as we extended the functionality adding voice interface and telephone alerting and remote support, etc.
We had groups of machines running a huge data center (they replaced the operator's console) with one of those running continuously for nearly four years, non-stop. For some reason back then the PCs didn't have to be "updated" or "patched" every other Tuesday just to keep working - so the Windows NT 3.51 and Window NT 4.0 machines just kept running, running, running...
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I've run into similar situations. I usually write them like a "microkernel" - and make a message/signal passing system usually on top of the OS's mechanisms (GUIless window handles in windows or signals in unix)
the microkernel is basically just a router/dispatcher and is the only thing that is always loaded. sometimes i make them hotpatchable via bootstrap.
but then yeah, the rest of it is in separate binaries.
i used to do a lot of real time embedded for critical systems and so this came up a lot.
but you can't write realtime code in .NET anyway. =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Sometimes it is possible to merge these little f*ckers into one DLL or EXE with the help of ILMerge or Fody Costura.
I also found this useful in case of conflicts with projects using different versions of NewtonSoft.Json.dll 
|
|
|
|
|
makes one wonder how many projects would be this way if Microsoft had thought to make static linking a first class function of .NET
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
maybe some manager decided to separate it into lots of DLL's by lots of different programmers so no single person had all the pieces to steal the application.
in real life some companies do do this with regard to part manufacturing in China
...often not realizing many of those companies actually sub the work (or are commission agents) for the same large [actual] contract manufacturer
Message Signature
(Click to edit ->)
|
|
|
|
|
seems silly in .NET's case due to perfect type info / reverse engineering.
An obsfucator won't slow down someone who worked on the project much, I think.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
shhhhh, don' tell the managers
Message Signature
(Click to edit ->)
|
|
|
|
|
As a rule, I tell managers as little as I absolutely have to. It's better for everyone that way.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I see I'm not alone in this sentiment.
Too bad that this is not a question of democracy. 
codewitch honey crisis wrote: think context is important
A pearl of wisdom. What will come next? Water is wet?
codewitch honey crisis wrote: there's a time and a place for lots of DLLs (like server code) and times when it's overdone
ANd yet another pearl of wisdom! As if there was anything that will not become problematic if it's misused.
codewitch honey crisis wrote: I'll cede that if you will.
Too gracious.
If you have several products, it might be wise to have shared components, so that all the projects profit from matured and well maintained code. The result is a pile of DLLs, but that may be a sign of quality and nothing bad at all. No matter where it appears, server or not.
And now follow me to the Emperor. He will show you the Dark Side.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
If your DLLs are 16k is it worth sharing binaries rather than including a source file?
Adding, as long as we're pointing out the obvious, no this isn't a democracy. Duh. I am emperor of my own projects, and my supers are emperors of my professional projects. Whomever the IP goes to is the arbiter of what it looks like. Water is wet.
Note: I wasn't calling for a vote. Also obvious.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: If your DLLs are 16k is it worth sharing binaries rather than including a source file?
Size is irrelevant. The contents do. For example, I have a tiny DLL that only implements the baseclasses and interfaces for presenters and views for the MVP pattern. With this I was able to port an application from WebForms to WinForms, from there to WebForms and from there to my own UI that runs in a 3D engine under DirectX. All I had to do was to rewrite the views, which still were dependent on the presentation technology. That's all.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
interface DLLs are fair because of the way .NET works. In the general case however, we'll have to agree to disagree.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
And what exactly is the general case we don't agree on?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
that an assembly should do just one thing
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Then you will sooner or later end up in dependency hell or have to live with redundancy. Both are not very pleasant and can make your projects unmaintainable. Is that really what you want to defend? Your right to shoot from your hip instead of putting some thought into your architecture? Or do you like to beat your code into submission. That may be fun for a while. Even quicker, which will make your bosses happy. At least until they discover that you have painted yourself into some corners which you can't get out of anymore.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
There are ways to address redundancy that don't lead to overfactoring. Proper factoring can limit redundancy and still not require 60 flipping DLLs
If you saw my projects you couldn't level the criticism of them you're leveling.
But then I grew up on C++, and the days where programs still had reasonable install bases on them.
My DLLs average about 60k to 150k in .NET. Not 16. And I don't have those problems you mention.
But then, I also use some tricks to keep the source manageable and the maintenance down.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: If you saw my projects you couldn't level the criticism of them you're leveling.
That would be nice.
codewitch honey crisis wrote: There are ways to address redundancy that don't lead to overfactoring.
Yes, but redundancy is the only way out of a circular reference. No compiler plays along with a circular reference for good reasons and if you mix different purposes into one stew in a single assembly, circular references are only one step away if you ever need to separate these concerns afterwards. You are on the safe side when you do that in the first place.
codewitch honey crisis wrote: But then I grew up on C++, and the days where programs still had reasonable install bases on them.
And I started out on machine code and hex keypads. The scope and ambition of the code I worked on since then has grown constantly. And it's certainly not true that we had no use for the #include preprocessor directive in C or C++. With all benefits and consequences, like the Win32 DLL hell.
codewitch honey crisis wrote: My DLLs average about 60k to 150k in .NET. Not 16. And I don't have those problems you mention.
Good to hear, but size is still irrelevant. More interesting is if an assembly contains all that is needed, no less and no more. You can't measure adequacy in bytes.
codewitch honey crisis wrote: But then, I also use some tricks to keep the source manageable and the maintenance down.
Some people prefer to call that architecture. Tricks often are more trouble than they are worth.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I'm giving you broad strokes as to how much code is in one. period. Not intended to be a metric of functionality but simply to give an idea of the ballpark of how much code i tend to put into one.
Includes are fine if you use them appropriately. Great in some cases.
Some people prefer to call that architecture. Tricks often are more trouble than they are worth
And how do you know what I mean by tricks? all it is is a shorter way to type technique.
Technique is not more trouble than it's worth.
I think we're done here. Like I said, we'll have to agree to disagree and we've both said what we needed to say.
In any case, I have stuff to work on, I'm not looking to argue endlessly about this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
No need to get angry. Anyway, over here it's already getting late and almost time for bed. The planet is not flat after all. How about a prayer at bedtime:
Quote: God, grant me the serenity to accept the things I cannot change, courage to change the things I can, And wisdom to know the difference.
Good night!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I'm not angry. I'm just done. Good night!
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I have to disagree. A class, and therefore it's assembly, should do one thing and one thing only. if you're not segregating your functionality across multiple assemblies, then you probably have a few different problems.
For one, It's harder to share code across apps. Consider a DAL assembly. it has one purpose - work on the DB. Multiple apps can use the same DAL assembly. Separating it into its own assembly mean greater code reuse.
And, as others have said, it's a whole lot easier to update a small assembly than a large boated EXE.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I don't believe every class deserves its own assembly. An assembly should perform a series of tightly related tasks, not a single task, but that's me.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I don't believe every class deserves its own assembly.
I didn't say that. I said each class should do one thing. And each assembly should do one thing.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
