Is there any limit on number of classes that a namespace can have in .net ? Further what is the recommended number of classes that there should be in a namespace?
views:
412answers:
7As far as I know, there is no such limit, in the same way that there is no limit to the number of classes you can have.
The namespace is simply part of the full name of the class.
There's no specified maximum number of classes "per namespace"-- a namespace is really just a part of the Type's full name, not a logical entity in the CLR
The recommended number is whatever makes sense: use namespaces to group logically related classes together.
I'm sure that if you have enough types you can run the compiler or the runtime out of memory, but that's a physical limit not a specification - and it probably doesn't matter if they are in the same namespace or not.
Note that as Steven points out, you can also have the same namespace present in multiple assemblies as well.
No limit. The feasabe number of types depends on the problem domain. If a certain "folder" as many types you have any freedom. In my application I have a namespace for messages in a certain protocol and I have around 200 different message types.
There may or may not be a physical limit, but you should reach a logical limit well before getting there.
As for "how many should there be," the answer, like most in .Net, is "it depends." There is no clear-cut answer to that - basically, you want to logically divide your solution into projects related by functionality or purpose - whatever makes sense in your particular case, and for your particular tastes.
You can always create a new assembly with more classes in any given namespace. No compiler can practically enforce a global limit.
Well, a class name has to fit into a string. There are only some valid characters, so giving that as a very rough guess as 850000 because I can't be bothered getting a count of the characters in different classes in the UCS, this would - in a namespace of one character-length name - give a limit of 850000x10737418213!x10737418213!. However, VB.NET can only work with names of 1023 characters in size, so that would limit it to 850000x1021!x1021! and C# can only handle 511 character long names, so 85000x509!x509!
I haven't a .NET4.0 framework, so the big-numeric math needed to work those equations out is too compliated to bother with right now ;)
The 85000 is probably well off, but ideographic characters are generally in the Lo class, which is allowed in class names, and they fill out a very large chunk of the assigned code-points. In any case, this whatever the real value is will increase with later Unicode versions.
All manner of technical and even physical limits will be hit before this point anyway, but way, way before then we hit the purposeful limit. The namespace doesn't exist for the compiler, it exist for the humans. The compiler could deal just as well (indeed, perhaps better) if there were no namespaces and coders just guaranteed never to reuse names. Namespaces exist for human beings to have reasonably-sized (learnably sized) groups of types to deal with.
I tried it out: I just built an assembly containing 1,000,000 types without any problem. However at 5,000,000 the C# compiler ran out of memory :-).