Five Questions on Code First in Entity Framework
Gil Fink is a senior architect for the Sela Group and a Microsoft MVP focusing on data platforms. In the May issue of Visual Studio Magazine, Gil wrote a feature exploring the new Code First features in Entity Framework 4.1 ("Not Just a Designer: Code First in Entity Framework"). We followed up with Gil on his thoughts about EF 4.1 and the impact of Code First for .NET developers.
Visual Studio Magazine: Having worked with EF 4.1 and the code first features, what are your impressions of what Microsoft has delivered to developers? Has Microsoft finally filled out the EF feature set, which was obviously not complete in the initial iterations?
Gil Fink: Since EF4 Microsoft is improving the EF stack rapidly and making it a worthy OR/M. There are many other improvements that are needed, such as Enum support, database migrations and the like, but the EF team is working on these features currently. When comparing EF4.1 to EF1. there is a huge improvement in the framework. One last thing is that the EF team is listening to the community and considers things that the community is raising in order to improve the tool.
VSM: Entity Framework has come a long way since the Vote of No Confidence from the MVP Community. Has Microsoft fully addressed the concerns of this constituency? Is there any reason .NET dev shops should hesitate to adopt the technology?
GF: There is no reason for .NET developers to hesitate to adopt EF. The framework is more mature now and includes a vast set of features that puts it in the front line of OR/M tools. Even so, an OR/M solution isn't a silver bullet solution to every problem, and when developers are going to make a decision about whether to use an OR/M or which framework to use, they should invest in a small proof of concept in order to see whether the OR/M solution is suitable to their demands.
VSM: When would the Code First approach be preferable to the Database First and Model First implementations provided in earlier iterations of EF?
GF: The Code First approach is preferable in small to medium applications that you are starting from scratch. It gives the ability to develop the domain model and then uses its conventions engine in order to generate the database. When you have a legacy database already, or a very big database, you probably will want to use the Database First approach instead.
VSM: Microsoft pulled support for pluggable conventions in the final version of EF 4.1. Why was this done and what do .NET developers lose as a result of this decision?
GF: The pluggable conventions were omitted in the release of Code First because the EF team wanted to wrap up the EF 4.1 package and the pluggable conventions were still in development. This was a major decision that the team took, since pluggable conventions were meant to enable the developers to plug their conventions into the Code First built-in convention engine, and by that provide an important extension point. We will probably have to wait to the next EF version in or to get the feature.
VSM: Any advice for developers looking to migrate to EF 4.1? How can they prepare to ease the transition for their existing applications and databases? Are there any common mistakes that they should look to avoid?
GF: The migration into EF 4.1 is very easy. Since EF 4.1 is built upon EF 4 and only adds new features to the EF stack, then all the developers need to do is to install the package (using NuGet package manager or downloading it from here) and use the new feature sets. There are new improvements in EF 4.1, such as the lightweight DbContext and DbSet that the developers will need to learn about, but nothing is going to change in the other feature sets of EF4.
Posted by Michael Desmond on 05/12/2011