C
Craig Deelsnyder
I would say that the projects should be divided logically into reusable
units, not too big, not too small. Most times, most of your projects are
built into a class library, which is a .dll that someone else can use in
their project, or know is in the GAC, etc. You want to structure them
logically, whatever makes the most sense. Most often you'll have a security
library (project/dll), data access library, etc., as these are components
most other projects need, and is the logical unit they'd borrow at.
Then all you have left are the actual projects that are your applications.
They use these class libraries you've already built.
My opinion is that there should only be one class per file. It's an old
habit from Java, and makes it easier to navigate thru your code.
And yes, everything should go into a namespace, which can also be set at the
project level. But I recommend another old Java habit, of having all
namespaces start with your company's internet domain name backwards...if you
are company ABC at abc.com (just pretend
), then all packages from your
company should be named
com.abc.security
com.abc.apps.app1
com.abc.....
etc. This way, if you ever distribute your library, you're almost assured
it will have a unique namespace. Don't know if this practice ever caught on
in .NET, but it was the way we did it when I used to do Java....
HTH, just some ideas....
units, not too big, not too small. Most times, most of your projects are
built into a class library, which is a .dll that someone else can use in
their project, or know is in the GAC, etc. You want to structure them
logically, whatever makes the most sense. Most often you'll have a security
library (project/dll), data access library, etc., as these are components
most other projects need, and is the logical unit they'd borrow at.
Then all you have left are the actual projects that are your applications.
They use these class libraries you've already built.
My opinion is that there should only be one class per file. It's an old
habit from Java, and makes it easier to navigate thru your code.
And yes, everything should go into a namespace, which can also be set at the
project level. But I recommend another old Java habit, of having all
namespaces start with your company's internet domain name backwards...if you
are company ABC at abc.com (just pretend
), then all packages from yourcompany should be named
com.abc.security
com.abc.apps.app1
com.abc.....
etc. This way, if you ever distribute your library, you're almost assured
it will have a unique namespace. Don't know if this practice ever caught on
in .NET, but it was the way we did it when I used to do Java....
HTH, just some ideas....