Setting up multi-tier project

[Ropje]

We have started de development of an n-tier project in VB6, but we are all experienced VFP-programmers.
We already solved a lot of questions, but some remain.
My question is about projects and project groups.
How would you set up the application, knowing we are about 12 developers, and we decided that some of us are responsible for the DataServices/DataAccess, and other are for the Business Logic.
My concern is that if everybody has access to all the layers, the layer-borders(?) will not be maintained the way they should be.
I was thinking about making different projects, and giving the BLdevelopers the .dll with an interface description.

We have 5 layers DS/DA/BL/Facade and GUI(Xml/Html).
We think we know what we're doing, but we are not used to the VB6 IDE.

Ropje

If all you have is a hammer, everything looks like a nail.

 

[chiph]

Ropje -

5 layers sounds like quite a lot of layers! But if you're sure you want to architect it that way....

I've found that if you're using source-code control (and you should be!), the MS SourceSafe tool is pretty good, once you've applied the service packs to it (it's in the Visual Studio group).

Once you've set up SourceSafe, you need to design a source-code tree. Issues here are dividing up the app so that people can work on different parts of it at the same time, planning versions, and deciding on a structure. Set up a small VSS project with some junk files in it, and pretend to go through two versions (a 1.0 and a 2.0) to see how it works. You'll want to have access to your 1.0 after you start work on the 2.0 so you can fix bugs, etc. and also make sure that the fixes make it into the 2.0 release. Afterwards set it up "for real".

Once you've got that done, it pretty much dictates the directory structure your source code will follow. Each project/version will have it's own directory, and each team can work on it without stepping on another team's toes. I don't personally use projectgroups that much -- I prefer to run multiple copies of VB to ensure that components which are intended to run out-of-process truly do.

For controlling who has access to what, you can set permissions in VSS so that only certain teams have write access to certain projects. Everyone else gets read-only access so they can do builds. I would read-up on ActiveX versioning, and setting COM compatibility. If you get it wrong, it'll be a pain later to fix (your registry gets cluttered up with a zillion incompatible versions of components).

Hope this helps some.

Chip H.