How Do you Organize your Code?

  • Thread starter Thread starter Larry Bud
  • Start date Start date
L

Larry Bud

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?
 
I generally start with a prototype to get the basic idea down, test
patterns, etc. I then move to organizing the framework of my application.
This is the most time consuming part, but it is a worthwhile exercise.

If you do not have time to do it all yourself, you can shortcut with other
people's frameworks. For example, you can purchase the .NET Design Framework
cheaply from www.dofactory.com. It has a reference application included,
which will help you get started. I am not in agreement with the entire
setup, for my implementation, but it does have you set up the code in a way
that is highly maintainable.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)

************************************************
Think outside the box!
************************************************
 
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
 
Mark Rae said:
Really? Every DataSet has its own separate project?
Click to expand...

I liked the part where he says "...but might have many classes in an
assembly...". Pretty much all my non small console-based apps have many
classes :)

Mythran
 
I liked the part where he says "...but might have many classes in an
assembly...". Pretty much all my non small console-based apps have many
classes :)
Click to expand...


Quite so! I can (just about imagine) having a separate class for each
DataSet, but an entirely separate project...?
 
Back
Top