text: ?
  Well it would be nice if Entity Framework offered an InMemoryDbContext, and just gave you the ability to create it in your unit tests. Since that doesn't exist, I'll show you how to build your own.
  To skip this reading and go straight to code, you can download the GitHub example now. This post assumes you have a basic understanding of Entity Framework.
  Let's Do This!
  Entity framework is a really good Object Relational Mapper (ORM), definitely better than it used to be. If you are going to be using SQL Server as your backend, then you should definitely consider it as one of the leading contenders.
  The first change to your code you will need is to use the interfaces. Let's look at what needs to change by looking at the final result.
  using System.Data.Entity; namespace NoRepositories.Core { public class NoRepositoriesDataContext : DbContext, INoRepositoriesDataContext { /// <summary> /// 2. There are two things to notice here. /// a. The use of IDbSet instead of DbSet. EntityFramework will /// be smart enough to set this as if it were a class of DbSet. /// b. the 'virtual' keyword is needed for lazy loading, but also will /// allow us to override this property if we inherit this class. /// /// note: virtual is your friend. Use it in your classes because it makes /// unit testing very easy with no need for mocking frameworks like /// Moq and Rhino Mocks. /// </summary> public virtual IDbSet<User> Users { get; set; } } /// <summary> /// 1. The first thing you should do is create an interface for your datacontext. /// Advantages to using an interface include but are not limited to the following: /// a. Dependency Injection ready for your favorite IoC container. /// b. Easily Mocked / Stubbed for your unit tests. /// c. You could switch out if necessary (unlikely and not recommended). /// </summary> public interface INoRepositoriesDataContext { /// <summary> /// 3. Notice we are mimicking the properties and methods we /// will need to access from our business logic, but that /// this is really simple. /// </summary> IDbSet<User> Users { get; set; } int SaveChanges(); } public class User { public int Id { get; set; } public string Name { get; set; } public string Email { get; set; } } }
  Notice, I've created an interface for my DataContext. Then I've changed all my DbSet properties to use IDbSet which is built into EntityFramework.
  Your next step is to inject your DataContext as a dependency. You could use an IoC container or just do it manually.
  var controller = new HomeController(new NoRepositoriesDataContext()); public class HomeController : Controller { public INoRepositoriesDataContext Db {get;set;} public HomeController(INoRepositoriesDataContext db) { Db = db; } }
  Notice we are still using the interface here and not the class itself.
  Thirdly, we just need to create the in-memory version of the database.
  /// <summary> /// 5. We can create the datacontext as a fake class or use /// our favorite Mocking Frameworks. But this is easier. /// </summary> public class FakeDataContext : INoRepositoriesDataContext { public FakeDataContext() { Users = new FakeDbSet<User> { FindResult = (objs) => Users.FirstOrDefault(u => u.Id == (int)objs[0]) }; } public IDbSet<User> Users { get; set; } public int SaveChanges() { // you can customize your data context to do whatever you want return 1; } }
  FakeDbSet is a class designed to have most of the implementations of a regular DbSet without going to SQL Server. This is all in memory.
  Finally, you can write your unit tests, with the speed of in memory access and the ability to seed data.
  [Fact] public void Can_fake_user_data_from_datacontext() { // We are using the interface, this can be injected. // 1. We can inject it into a controller! // 2. We can inject it into a service! // 3. We can inject it into a worker! // 4. We can inject it anywhere!!!!! INoRepositoriesDataContext context = new FakeDataContext(); // let's add a user context.Users.Add(new User { Id = 1, Email = "test@test.com", Name = "test user" }); // Hey we have a user Assert.True(context.Users.Count() == 1); // Hey we need to run linq var user = context.Users.FirstOrDefault(u => u.Id == 1); Assert.NotNull(user); // Hey we need to use Find user = context.Users.Find(1); Assert.NotNull(user); // let's call SaveChanges (with no consequences or database). Assert.True(context.SaveChanges() == 1); }
  Conclusion
  There you have it, an in-memory version of your DataContext, with no SQL Server insight, no repository pattern, you get to keep LINQ, and all your developers stay happy :). One thing to note is that this is great for testing your logic, but you might have some discrepancies between how your code behaves in memory and how it behaves when integrating with SQL Server. Please plan for the environmental differences accordingly.
  Now go clone the code and see it working on your machine!
  Nice approach.But Can you elaborate more about this sentence "but you might have some discrepancies between how your code behaves in memory and how it behaves when integrating with SQL Server".How to achieve that or things we have to do ?
  Nice article! What do you think about only executing queries in the data layer, and returning IEnumerable instead? I like repositories because of that, and because I can make some filter methods like GetShippedOrders. Thank you very much!