# 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:

1. UI (my MVC project)
3. 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<Order> GetAllOrders()
{
DataContext db = new DataContext();
return db.Orders;

}


ShipmentsBLL.cs

Public IEneumerable<Shipment> GetAllShipments()
{
DataContext db = new DataContext();
return db.Shipments;
}


ViewModels.cs

public class ShowAll
{
public IQueryable<Order> order { get; set; }
public IQueryable<Shipment> 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?

• Have you tried Neos-SDI MVC4 Template? It's a good start for creating a MVC n-tiers web site. Once this template is installed, it will create for you all your layers, use injection between layers. – user22463 Feb 23 '13 at 14:42