|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
in cases like one click deployment and small self installing packages (like utorrent is or used to be?) it's nice to not have to lug around DLLs.
it's also easier to write installers and maintain them when you don't have (like another commenter lamented) 2000 DLLs in a project. Even 60 is a chore.
Better to keep it to a few, maybe a dozen for middling-to-large applications.
Server code is a different story for a number of reasons.
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: Server code is a different story for a number of reasons.
Why, actually? A good layered architecture always is a good idea, no matter what it's for or where you want to deploy it. In a way, layers are just another way to separate concerns.
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.
|
|
|
|
|
because server code is more liable to need hotfixing and this is easier with highly segregated DLL code.
And you can architect things and factor them out without putting everything in separate DLLs.
because server code doesn't really need things like click-deploy - server code usually has complex deployment in place anyway, so the infrastructure for supporting all those files is already in place.
because server code needs to be updated without bringing the server down, which isn't generally an issue in user applications.
Classes are for layering. You don't always need DLLs for that.
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.
|
|
|
|
|
Unless something has changed, .NET can handle DLLs in a unidirectional way. That is if DLL A references DLL B, B cannot reference A.
Ran into this on a project where most the UI would be in the EXE, some in one DLL and all the non-UI base logic in a third. Then we discovered the above and two DLLs became four. I soon left that train wreck, so I've no idea how it ended up.
|
|
|
|
|
Try front-end development.
npm install whatever
Your npm folder now has 12641 files for a total of 2.4 MB.
|
|
|
|
|
Are you trying to reference a ".NET Standard 2" library from a project targetting a .NET Framework version earlier than 4.7.2? That'll give you lots of tiny support assemblies to provide the "standard" features that weren't available in earlier versions. Changing the project to target 4.7.2 or later should get rid of them.
Using .NET Standard with Full Framework .NET - Rick Strahl's Web Log[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
no, i'm talking about opening a VS solution and having 60 projects in it.
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'm for one or two bigger Dll's, especially if i have multiple exe's accessing the same classes.
i don't see the point of beaking a ptoject into tiny pieces, especially when they have to work with each other.
I'm still of the mindset to keep my code as small as possible because of many years of updating customer software over Dialup. if the whole compiled project got over 2mb i was doing something wrong and needed to refactor.
|
|
|
|
|
All of this I agree with.
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've never used a DLL in a .NET ptrogram, because I hate dealing with the problems they create. I statically link the libraries I need to access and make the installation process clean and don't worry about DLL conflicts. That's a lesson I learn back with DOS.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
.NET doesn't suffer from most of those old problems with DLL versioning.
It is an extra dependency to drag around as part of the install base though so i feel you.
There is certainly a place for simple install bases, and i think it applies to smallish user applications and services.
sometimes i get *really* extreme and make small .net services and the like "self installing"
mysvc /install
mysvc /uninstall
then i don't even have an installer. =P
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
