Multi Developer Guidelines/Best Practices

W

Will

Our shop has 6 .Net developers, most of our work to date has been one
developer on a project at a time, occasionally 2 for brief periods of
time. We have souce control (SourceGear) and love what it does for us.
We have a mixture of C# and Vb code (some prefer one versus the other,
all of us feel comfortable looking over either when needed), but we are
leaning more toward C# as time goes on. We have a mixture of Web
applications and Windows applications. Our Windows applications tend
to be larger scale. In Windows applications, we separate business
logic from the forms in separate class libraries.

Now we are tackling a larger project (Windows application) where we
want to have 4 or 5 of us working together. Our thoughts are to have 3
assemblies:
Main Project - will contain Main, instance forms that inherit base
functionality from base forms, common functionality classes like
messaging, error handling, etc.
Base Forms - will contain the base forms
Business Classes - will contain the business logic class libraries

One developer will be responsible for business classes (less
experienced in .Net but very familiar with the business logic for the
applicaiton), one developer (less experienced) will be responsible for
the instance forms, and 2 of us (seasoned .Net developers) will be
responsible for base forms and common functionality. The 5th developer
is also seasoned and will be helping the 2 less experienced developers
and acting as a backup in all areas.

We like the idea of seperating the tasks into 3 projects, but there is
some concern that we will have circular references (project A
references B and B later references A). We aren't locked into the
design yet, but need to very soon. Any thoughts on how best to
organize the various parts of the application?
 
T

Thunder

In order to circumvent the "circular ref" problem, you need to create a
project that contains Interfaces. Your ""Business Object" and "Data
AccessLayer" project can ref the Interface project. When you pass in
"objects" to the DAL for processing, you can cast them as the Interface for
the given BO.

Most system I build use a set of dedicated BO, DAL & BE projects. The BE
stands for Business Entity and that project holds the interfaces for the
BOs.

Be sure to create a separate project for GlobalItems and be sure to set the
serialization attribute on all your BOs and BEs. Also, be sure to make
decisions early on the use of ".NET remoting v.s. "Serviced Components"

-Michael Bowman
Team Vertical Works
www.verticalworks.com
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top