How to architecture a 3-tiered solution?

I am using FluentNHibernate in my solution. The recommended folder structure from fluentnhibernate documenation is like this:

Entities folder, under which we have POCO classes of the business model. Mappings folder, under which we have the mappings to our data model.

I assume that these two folders would go into a business layer project called "BusinessModel"? See below:

BuessinessModel
    |_ Entities
          |- Student.cs
          |- Course.cs
          |- Faculty.cs
    |_ Mappings
          |- Mappings.cs

And maybe create another project called "DataAccess" which references the BusinessModel project for the data access layer to do the CRUD?

What's the best practice? Any architect there? Thanks.

AK: I read your post at n-layered architecture - BLL, DAL and interfaces. What is best practice? .

Let me quote yours

Taking a "Person" as an example: think about the different data operations associated with a person (Getting all the data for a single person, a collection of shallow data for many persons, CRUD operations, searching, etc) - then design interfaces along logical groupings.

I am trying to understand this. So, you are saying that

In the BLL project, we have this Person class.
Also in the BLL project, we have an interface which declares all data operation methods we will need for the Person object.
Then in the DAL project, we have concrete implementation of the interface we define in BLL.

Does this sound correct to you? Thanks.

Solution

While it's dangerous to go blindly applying the same architecture to every solution / project; my standard / default approach would be something like this:

High Level

we're aiming for 3-Tiers, which we assume are: UI, BL (Business Logic), DA (Data Access).
That's going to (probably) be made up of the following 4 logical chunks (think namespaces) of components: Common, UI, BL, DA. Keep in mind that each of these 4 chunks will probably have more than one code level project.
Common is where we'll stick things which the other 3 need to share - POCO's for example.

Your Specifics

Make BusinessModel (probably as a standalone project) inside Common.
Mappings I'm guessing is dependent on the physical data source, so that should go into the concrete DA implementation.

Other Notes

Best / common practice is to loosely couple our main chunks (especially the BL and DA); usually using Dependency Injection.
This will be achieved by defining Inferfaces, and these interfaces will/can use the POCO's or your BusinessModel entities - from the Common.