@ken2k pretty much rounded the bases, but I just wanted to point out that while it is inadvisable to utilize the repository pattern with EF, it's not a bad idea to still abstract away your use of Entity Framework. What I personally use is the strategy pattern, where I create an interface that essentially holds an API that my application can use, and then one or more implementations of that interface, depending on what kind of sources I'm dealing with (Entity Framework, Web Api, etc.). In your application, you only ever refer to the interface and then use dependency injection to substitute the appropriate implementation. This allows you to swap out "strategies" at a later point. For example, if you later find yourself wanting to switch from EF to something like Dapper, you need only create a new implementation for Dapper and then swap it in with your DI container. The rest of the application hums along none the wiser.
Also, I find it beneficial to have my entities implement various interfaces, which then allows me to create generic methods in my strategy implementations that can work with similar types of objects. For example, I might have something like:
public interface IPublishable
{
PublishStatus Status { get; set; }
DateTime? PublishDate { get; set; }
DateTime? ExpireDate { get; set; }
}
Then, I can implement a method like:
public IEnumerable<TEntity> GetPublished<TEntity>()
where TEntity : IPublishable
{
...
}
Inside that method, I can freely query my entities using Status, PublishDate, and ExpireDate, since the interface guarantees that any class eligible to use this method has those properties.
