Many applications I’ve encountered and most of my first applications had
loose or no defined architecture.   From a high level, everything just was.  And
it worked.  And it became hard to maintain.  I’ve been researching better ways
to organize the application and how to take advantage of high-level design
patterns.  With this knowledge, I’ve developed a general architecture for any
application with a UI (apps without a UI will just lack that layer, and, of
course, I haven’t included a service layer (which might even be the interface
layer).

My goal was to describe how the layers might interact and what bindings would
exist.  The most important things follow:  The UI layer holds references to the
process and business layers and no others.  The process layer holds references
to the repository, business, and UI layers.  The repository layer references
business and DAL.  The business layer references nothing (and this is key for
object portability).  The DAL references only the database (most likely through
the connection string) but holds no assembly references except ADO.NET, of
course.

With this architecture, we can implement Model-View-Presenter,  Repositories,
and Observer.   For example, the Process layer would hold presenter objects that
invoke business objects and set the View (UI).  The View observes business
objects but does not control them.  The Presenter objects control the process
layer and invoke the repository classes to get or persist the business objects. 
The repository layer does this by calling the correct classes of the DAL.  And
then, if the database changes (either in vender or schema), only the DAL needs
to be changed.  The DAL should expose classes that return data by calling the
right query in the database.  The DAL might wrap ADO.NET or perhaps the Data
Access Application Block for the direct database access.  The DAL would know the
names of stored procedures.  The repository objects would not know this.  Rather
the repository objects would just know what class and method to invoke to get
information with which to populate a business object.  The DAL should return
generic objects such as an IDataReader. 

I’ve read a lot about application design patterns and best practices, but I
wish there was some more architecture guidance out and about.  I think the
industry would benefit from standard approaches to application development from
a high level.  We hear a lot about n-tier and business layers, but a business
layer that knows how to persist its own objects is not the way to go, so I see
this guidance lacking.

Feedback is welcome on the above diagram.