Here's what we do Mike:

We have 4 "layers" ... UI, Web Services, Business, Data Access.

These are more than 4 projects, because each layer is further broken down by module. Let's take the DataAccess layer as an example:

As in all our layers, there are DataAccess parent classes from which all DataAccess classes inherit. These parent classes have all the basic functionality needed for DataAccess and we consider it part of our "framework" ... it has it's own project. Each module in our app has a separate DataAccess project. So, we'll have a DataAccess.Personnel project and a DataAccess.Inspection project, etc. and the classes in those projects inherit from the parent classes in the "framework" project. (As you probably know, these separate projects become separate .DLLs).

The Business layer got a little more complicated, but the architecture of it is the same. We actually have 2 Business layers ... server-side and client-side. The server-side classes remain on the server where they are accessed from the Web Services. The client-side classes are brought down to the client from the server to be used by the UI classes, but they can also be used on the server.

Does this help at all?

~~Bonnie



>Just a few general architecture questions...
>
>We have a few ASP.NET systems. They are split into multiple projects per system - 1 for Biz, 1 for Data, and however many for UI (some have separate "maintenance" UI's).
>
>Is this the proper architecture? Should I be concentrating on making 1 large business layer and 1 large data access layer for all projects? Or is having a separate biz layer and data layer that inherit some common functions from a utility layer the way to go? What is everyone else doing?
>
>It's always nice to have some reassurance that you are going in the right direction... ;-)