title: ASP.NET MVC using the Repository Pattern
body: <p>Currently im using EF and using its datacontext directly in all of my actions, but since i started reading about loose coupling and testability im thinking that thats not the best way to go. Im trying to understand all the pro's and con's before i start refactor all my current code.</p>
  
  <p><strong>Problem 1:</strong>
  Considering that every entity needs its own repository, and thus has to setup its own connection to a datasource (lets assume a database using EF), wouldnt that give alot of overhead if i need data from 5 different entities on a single page?</p>
  
  <p><strong>Problem 2:</strong>
  What im seeing aswell in all the examples which i found online is that most people (even people like shanselman) implement the repository pattern using the entity classes which are generated by either LINQ or EF, doesn't this defeat the purpose of repository pattern with regards to loose coupling? On the other hand, what is the alternative, using POCO classes in combination with for example AutoMapper? (this scares me a little)</p>
  
  <p>Im hoping that a few people can shed some light on this, because im a bit confused at the moment if the repository pattern is the right choice for a website.</p>