It's hard to generalise, but I guess a typical project for us would go
something like this:
* A Presentation Layer Solution containing
* The Web site project
* Another project for the classes used by the callbehind code,
representing the state of the objects in the presentation layer.
* A business Layer Solution
* One project for each object in the business layer (because, for us,
they are single call SAOs. The project contains not only the object itself,
but also various test classes as well as the service host code and the code
for the remote object's interface.
* A Data Layer solution
* One project per Typed DataSet
There are also other projects that are not necessarily a part of the
particular solution, such as the project holding the Exception classes.
These could be contained in a project in the solution, but may equally be
added to an Exceptions solution (that holds custom exceptions for stuff that
will possibly be shared).
We generally stick to one class per file (although we might include more if
they are trivial), but might have many classes in an assembly if that's
appropriate.
HTH
Peter
"Larry Bud" <la**********@y ahoo.comwrote in message
news:11******** **************@ 57g2000hsv.goog legroups.com...
Been working with .net 2 since January, and am in the middle of my
first large project.
It's becoming obvious that one must organize their code well in a
large project to make maintenance easier. So what's your process?
Do you stick everything in one Class file? Do you have a separate
class file for each "type" of function.. i.e. one for all data access,
another for general math, another for string function, etc.
Or something I haven't thought about?
