I'm a Winforms programmer before; I always partition programs I write in two parts, the front-end(Winforms) and middle-tier(facilitated by Remoting/WCF)
On that approach, the front-end code cannot access the Linq or System.Data.SqlClient. But that has the added advantage that the middle-tier is an instant SOA-citizen (service oriented architecture), can be used in B2B scenarios, database-agnostic, and internet-capable even it's just a Winforms app.
Now I'm learning web skills. Using the SportsStore project from the book Pro ASP.NET MVC, it's inevitable that I would compare my old(?) approach (the middle-tier) and the repository approach on that book. The repository approach exposes the data access mechanism(Linq to SQL) directly on front-end(SportsStore.WubUI). Using the repository approach, the SportsStore.WebUI still has a direct connection to database.
Question is, on web programs, should I aspire making the front-end to interface only to a middle-tier(so the front-end can be database-agnostic and the middle-tier is an instant SOA-citizen), or should I use the database directly(by means of repository approach, ORM, or similar) on front-end?
I'm certain that the book has violated some best practices for the sake of brevity. Authors have to balance "how do I get my point across" versus "what is the correct way to do it"; they usually opt for the former (as they should -- this is a book about web development, not about architecture, right?).
You should absolutely continue to use n-tier architectures. The whole point of the n-tier architecture is to allow you to (more) easily swap out the layers -- switch databases, switch user interfaces (replace Winforms with ASP.NET, for example).