Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Abstract Interfaces vs Abstract Base Classes in Entity Framework 6

Abstract Interfaces vs Abstract Base Classes in Entity Framework 6

As part of the Beta 1 release, Entity Framework 6 has added support for mass inserts and deletes using the new DbSet AddRange and RemoveRange methods. These methods accept an IEnumerable and are processed when SaveChanges is called. Another DbSet methods, FindAsync was also added.

Adding these methods caused a design problem for the Entity Framework team. In order to make DbSet testable they had included a matching interface called IDbSet. In theory any mocks would implement this interface and all would be well. Unfortunately adding new methods to abstract interfaces is a breaking change, so what do you do?

Some of the ideas considered by the Entity Framework team included:

  • Make the breaking change. This is the route that Sun choose when it added new method to the JDBC interfaces in Java 7.
  • Make DbSet “more mockable”. In this context that means giving it a protected constructor and marking its methods as virtual. If the protected constructor is used, all the methods are treated as no-ops unless overridden. IDbSet could be marked as obsolete, as it would nothing over the real DbSet.
  • Use extension methods with delegation. If a real DbSet is available the extension method will forward the call to it. If only an IDbSet is available, reflection will be used to locate a matching method to invoke. Needless to say, this is going to make tests slower and static type safety will be lost.
  • Create a new interface called IDbSet2. (And in the future IDbSet3, IDbSet4, etc.)

The decision was recorded in the May 16 design meeting notes,

The decision was to make DbSet more mockable. However, we will not obsolete IDbSet because this would create work for those currently using IDbSet who don’t need to use the new members. We will add guidance to IDbSet indicating that using DbSet is the way to go for new code and, depending on feedback, we may choose to obsolete IDbSet in a future release.

In you are interested in the history of other design decisions made in Entity Framework, the design meeting notes are available as far back as May 31, 2012.

Rate this Article