Do you really need views? With LINQ to Entities
] you can write queries in managed code on top of the entity sets themselves (tables on the other side). The query will be transformed to actual sql query statements only when it is enumerated (this is called deferred execution). And as views are evaluated at runtime too (there is a little preprocessing, but not much) - in general you won't gain a lot. So, although you can use the database side views in your EF model (as Sandeep Mewara pointed out), you have to consider if you really need them.
Think like this: in the traditional development, the lot of the business logic is put on dbms side (views and stored procedures are in general such things), so the BL is split between two or more tires. The EF philosophy is treating the database more like a simple datastore, and is pushing the developer to forge the BL above the data access layer (with the application level entities in mind) - and not split or even below DAL.