I've now spent some time working with substantial existing "Enterprise" codebases, written in .NET and talking to a relational database (usually Oracle, but increasingly SQL Server too). Something I see over and over again is the separation of the web UI layer, a business logic layer, and a data layer. Then the database will have a set of stored procedures, and finally the underlying tables.

I wasn't surprised by this. Even while I was working on my previous Zope project, I understood that this was regarded as Best Practice by the Microsoft web/database development crowd.

But then I start to see code like this in OnPreRender:

GridView grid;
grid.DataSource = BLL.Customers.GetCoolCustomers();
grid.DataBind();

Digging into the BLL.Customers, class we see something like:

public DataView GetCoolCustomers()
{
  CustomerDao dao = new CustomerDao();
  return dao.GetCoolCustomers();
}

So we follow that into the data access layer:

public DataView GetCoolCustomers()
{
  DataView dv;
  ... do some ADO.NET dancing...
  return dv;
}

Hmm. Seems a bit redundant to me. Never mind, I can understand keeping a consistent set of layers (kind of, more on this later). So we go and have a look at the stored procedure that GetCoolCustomers ends up invoking...

... and it's invariably a 500-line monster, doing everything from filtering out customers not considered cool to formatting their names so that they display nicely on the screen.

What happened to the UI layer doing the display logic, and the business layer doing business logic? (At least the data layer actually does something in the above example).

So how does one end up with a design like this? I think the following factors all have a part to play:

• The seductive ease with which ASP.NET lets you bind web controls to underlying data sources. No code required! Except that you do need the code, as shown by the fact you've got a 500-line stored procedure driving this thing.
• People slavishly follow Best Practice without thinking whether it's appropriate in their situation. A layered design works great for large systems, where there's significant 'thinking' to be done at each layer. If you're just splatting tables on the web (so actually that proc is a 3-liner, not a 500-liner), excessive layering is a waste of time.