Gripe: No, you can keep your 60 tiny DLLs. I'll find another way.
-
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:
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.
-
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.
-
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.
-
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.
which in .NET is basically saying one class deserves its own assembly. I don't know how else to read it at least.
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.
-
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
Nor does he. He said that a class should only have a single responsibility and extended that to assemblies. I would also extend that to methods, which also should not be written to do everything and nothing at the same time. A class may have many methods, an assembly many classes, but they should share a common responsibility or you will very likely end up in dependency hell.
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.
-
codewitch honey crisis wrote:
I don't believe every class deserves its own assembly
Nor does he. He said that a class should only have a single responsibility and extended that to assemblies. I would also extend that to methods, which also should not be written to do everything and nothing at the same time. A class may have many methods, an assembly many classes, but they should share a common responsibility or you will very likely end up in dependency hell.
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.
adding, on reflection i think we're arguing semantics. I'd say an assembly is for tightly coupled tasks. i agree with you about methods and classes. There are no global methods in .NET. So if we're talking a single task, per class, and a single class per assembly, under .NET that means one class per assembly, QED
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.
-
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.
-
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.
-
adding, on reflection i think we're arguing semantics. I'd say an assembly is for tightly coupled tasks. i agree with you about methods and classes. There are no global methods in .NET. So if we're talking a single task, per class, and a single class per assembly, under .NET that means one class per assembly, QED
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:
So if we're talking a single task, per class, and a single class per assembly, under .NET that means one class per assembly, QED
Really? So you do think that a class may have several methods, yet an assembly can't have several classes that provide different aspect of the assembly's purpose? Remember my MVP pattern? That assembly had one purpose only: To implement baseclasses(!) and interfaces(!) for just that pattern without any dependency on any presentation technology. For example, a baseclass for views and another baseclass for the presenters. MVP will not work if you leave away the V or the P. :-)
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.
-
codewitch honey crisis wrote:
So if we're talking a single task, per class, and a single class per assembly, under .NET that means one class per assembly, QED
Really? So you do think that a class may have several methods, yet an assembly can't have several classes that provide different aspect of the assembly's purpose? Remember my MVP pattern? That assembly had one purpose only: To implement baseclasses(!) and interfaces(!) for just that pattern without any dependency on any presentation technology. For example, a baseclass for views and another baseclass for the presenters. MVP will not work if you leave away the V or the P. :-)
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.
Again, we seem to be arguing semantics, because as I said, I believe an assembly is for a series of tightly coupled tasks. I'd argue a method shouldn't even perform one full task or entity. That's what a class is for. Methods report, and sub-process. A series of classes that perform tightly related tasks are what belong in an assembly. For me that yields assemblies of about 100-150k when using generics, and generally 60k to 100k without them, or with sparse use of them. In the OP I'm talking about a 10th of that per DLL. I find it excessive. You (presumably?) do not. To each their own.
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 think it's a matter of degree. I'd put - for .NET - perfect being somewhere in the neighborhood of 150k and up, assuming generics are being used. Adding, my criticism of the installbase is more from a dev and maintenance perspective. Sometimes there's such thing as overfactoring.
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 think it's a matter of degree. I'd put - for .NET - perfect being somewhere in the neighborhood of 150k and up, assuming generics are being used. Adding, my criticism of the installbase is more from a dev and maintenance perspective. Sometimes there's such thing as overfactoring.
Ah, did you expect my perspective to be that of a dairy-farmer? :laugh: Sometimes I preload a DLL by calling a static method that does nothing. Forces the runtime to load the assembly and all its types. It makes life easier. Why would you prefer big executables containing duplicate code over that?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
codewitch honey crisis wrote:
i think it's a matter of degree. I'd put - for .NET - perfect being somewhere in the neighborhood of 150k and up, assuming generics are being used. Adding, my criticism of the installbase is more from a dev and maintenance perspective. Sometimes there's such thing as overfactoring.
Ah, did you expect my perspective to be that of a dairy-farmer? :laugh: Sometimes I preload a DLL by calling a static method that does nothing. Forces the runtime to load the assembly and all its types. It makes life easier. Why would you prefer big executables containing duplicate code over that?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
i meant as opposed to an end user's perspective i just prefer to factor assemblies by related task. i'm not sure what others do. If I find myself with a little bit of redundancy at the source level, I have a mechanism for "includes" in C#. If I find myself with a lot of it, that's where a separate assembly comes in. YMMV I don't see 150k as particularly large. .NET allocates 12 megabytes of heap as its way of saying "hi!"
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.
-
which in .NET is basically saying one class deserves its own assembly. I don't know how else to read it at least.
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.
Not really. You could have a DAL assembly with multiple DAL classes... one for SQL, one for Oracle, Access, ect. Multiple classes in one assembly. The classes each do one thing - deal with one particular DB, and the assembly does one thing - houses DAL classes. Putting your biz logic in the UI or DAL breaks this pattern. But you could have mutiple BL classes in one assembly
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
Not really. You could have a DAL assembly with multiple DAL classes... one for SQL, one for Oracle, Access, ect. Multiple classes in one assembly. The classes each do one thing - deal with one particular DB, and the assembly does one thing - houses DAL classes. Putting your biz logic in the UI or DAL breaks this pattern. But you could have mutiple BL classes in one assembly
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
i guess to me those are effectively separate because they are "interface DLLs" - something i mentioned to another commenter as an exemption to my rule of thumb. Sometimes, dependency requirements force us to create DLLs like this, or ones with just base types in them in order to fulfill something like that. but i'd consider each interface its own task, IMO. YMMV a lot of this really depends on which rubber rulers you're using.
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 meant as opposed to an end user's perspective i just prefer to factor assemblies by related task. i'm not sure what others do. If I find myself with a little bit of redundancy at the source level, I have a mechanism for "includes" in C#. If I find myself with a lot of it, that's where a separate assembly comes in. YMMV I don't see 150k as particularly large. .NET allocates 12 megabytes of heap as its way of saying "hi!"
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 meant as opposed to an end user's perspective i just prefer to factor assemblies by related task. i'm not sure what others do.
Others do "whatever works". I've often asked for motivations on behaviour, never get one.
codewitch honey crisis wrote:
If I find myself with a little bit of redundancy at the source level, I have a mechanism for "includes" in C#. If I find myself with a lot of it, that's where a separate assembly comes in.
Assume the programmer to be incompetent, and suddenly the rules that .NET abides to seem logical. If you don't use it, we don't load it. Assume your developers are VB6-fans. And to be honest, as a professional developer, I like it that way.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
codewitch honey crisis wrote:
i meant as opposed to an end user's perspective i just prefer to factor assemblies by related task. i'm not sure what others do.
Others do "whatever works". I've often asked for motivations on behaviour, never get one.
codewitch honey crisis wrote:
If I find myself with a little bit of redundancy at the source level, I have a mechanism for "includes" in C#. If I find myself with a lot of it, that's where a separate assembly comes in.
Assume the programmer to be incompetent, and suddenly the rules that .NET abides to seem logical. If you don't use it, we don't load it. Assume your developers are VB6-fans. And to be honest, as a professional developer, I like it that way.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I get it, but maybe i'm just more of the Bastard Programmer from Hell than you are :laugh: Props for the reference though. BOFH is legend.
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.
-
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.
-
Again, we seem to be arguing semantics, because as I said, I believe an assembly is for a series of tightly coupled tasks. I'd argue a method shouldn't even perform one full task or entity. That's what a class is for. Methods report, and sub-process. A series of classes that perform tightly related tasks are what belong in an assembly. For me that yields assemblies of about 100-150k when using generics, and generally 60k to 100k without them, or with sparse use of them. In the OP I'm talking about a 10th of that per DLL. I find it excessive. You (presumably?) do not. To each their own.
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:
In the OP I'm talking about a 10th of that per DLL. I find it excessive. You (presumably?) do not. To each their own.
I simply don't care as long as these assemblies contain what is needed, no more or less. Bundling things without need reduces your flexibility, which may get you in trouble. On the other hand it does not offer any real benefit other than looking nicer.
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.
