nTier architecture for an MVC application I am endeavoring to build my first non-trivial web application and so I'd like to confirm a couple of design decisions.

I have three tiers as follows:


UI (my MVC project)
Business Logic (separate project)
Data Access Logic (a simple .dbml that is part of project #2)


Is this a reasonable approach to separating concerns? Should my DAL consist of more than just my Linq .dbml file?

To play this out, lets say I have an Orders table and a Shipments table in my database.  Furthermore lets say that I want to pass a list of orders and shipments through to a page in the UI.  Here's how I'm envisioning that would work.

OrdersBLL.cs

Public IEneumerable&lt;Order&gt; GetAllOrders()
{    
DataContext db = new DataContext();
 return db.Orders;

}


ShipmentsBLL.cs

Public IEneumerable&lt;Shipment&gt; GetAllShipments()
{
DataContext db = new DataContext();
return db.Shipments;
}


ViewModels.cs

public class ShowAll
{
    public IQueryable&lt;Order&gt; order { get; set; }
    public IQueryable&lt;Shipment&gt; shipment { get; set; }
}


Then when I create the view in the MVC app to display all orders and shipments I would simply pass in a ShowAll object from the ViewModel.

Over all I think this approach separates concerns reasonably well.  However, I'd be interested in learning if others have a better approach.  One concern I have is that my approach requires instantiating Order and Shipment objects in the View Model.  However, these come from classes that are defined in my data layer.  This strikes me as a bad idea given that I read somewhere that only the BLL should talk to the DAL.  Is this correct?
An accepted design pattern for separation of concerns is the Repository design pattern.  There is a pretty good description of using this design pattern in MVC here. Your example is close to this pattern in your BLL layer, although your simple example does not have any business logic and just encapsulates the DAL.  If you need to access multiple Repositories for your view it is recommended to use a Service Layer that coordinates transactions between multiple Repositories.  There is a good description of this pattern here.

Your View Model should be totally separated from the BLL and not query it directly. I assume you are querying the results in the View since you are returning an IQueryable object.  The controller for the MVC should take any query parameters from the View, pass them to the Model (Repository or Service Layer) and get back an object graph that represents the View Model, which in turn is passed to the View.  The View Model usually does not clone the objects that are manipulated in the Repository.  For example you would not need to pass things like foreign keys used for navigation in the DAL to the View Model.  Only pass to the View Model what it needs to get its job done, which is to allow the View to render a user interface.  This usually requires a lot of data mapping from one object to another. Although it is a hassle upfront you will appreciate it going forward because you will have a code base that is not fragile to changes in either your model or view.  A good tool to help with the data mapping is AutoMapper.
For a great example on how to create a robust modern website using MVC take a look at Microsoft's Silk Project.