UPFRONT DISCLAIMER: Long post to follow. Made sense when I typed it, but I didn't re-read afterwards... 
Well, how I usually design is as follows:
- Database Layer
An assembly dedicated to performing database calls. I usually have a base-class which manages the connection to the database itself, as well as any exception handling. This class also exposes methods to perform various calls to the database, i.e. "Update calls" (insert / update / delete) and "Getter calls" (returning datasets, tables, scalars or return values). For each business entity in the system, I then have a separate database class, inheriting from the base class. This derived class then interacts with the necessary tables via stored procedures - NEVER direct queries.
- Business Layer
An assembly dedicated to handling all business logic and representing all necessary business entities in object form. The business layer is the ONLY assembly that references the Database Layer. I create strongly-typed objects with the necessary member variables, properties and methods so as to correctly represent them in context of the business. I also make sure that the objects can be correctly serialized to XML (i.e. that the necessary properties will be correctly serialized to attributes, elements, enum or even ignored), so that web services utilizing this assembly will always return the correct serialized XML representation of the objects.
- Interface / Presentation Layer
Finally, the Interface Layer just handles the display and user interaction with the business entities. The Interface Layer only contains a reference to the Business Layer assembly. I prefer working with objects, as the properties are a lot more intuitive than trying to bind to column names in a data table. Also, calling the "Update" method for a specific object gives you much more control over what goes in the database, instead of just committing a dataset's contents to the database and hoping for the best. When working with a web application, I prefer to serialize the business objects to XML and transform it with the appropriate XSLT file. It makes for a nice, dynamic solution that you can easily adapt without having to rebuild and -deploy a complete solution.
Of course, then you can always follow the MVC / MVP route. In terms of ASP.NET MVC, its still (iirc) in a bit of a beta-phase, so I would personally wait a while and see how it pans out commercially (
Stack Overflow is a nice example of a commercial ASP.NET MVC site though). I enjoy implementing a bit of a 3-tier / MVC hybrid solution though - I associate each business entity with a specific XSLT file, with a "RenderToHtml" method transforming the object's serialized XML with the specified XSLT file. You are still stuck with "web forms" then, but the data management of the objects are a lot more elegant. You could of course associate the object with a Web User Control or any other control collection as well. You could also just bypass the whole object serialization by returning XML directly from the SQL database and transforming it with XSLT. The possibilities are (almost) endless.
I tend to "complexify" a solution to make it scalable, easily adaptable and optimized, while still meeting the direct business needs of the application. Sort of, but not completely like building those "factory building factory factories"...
)
, 
)... I like to keep them apart, personally.
