Entity Framework goes 'code first' as Microsoft pulls visual design tool

Visual Studio database diagramming's out the window

Visual Studio

Microsoft will retire the visual design tool for its Entity Framework (EF) database tool in the upcoming version 7, in favour of a text-based “code first” approach.

Entity Framework is an object-relational mapping (ORM) tool. It lets developers work at a higher level of abstraction, coding with application objects rather than having to think about the SQL (Structured Query Language) that is sent to the database engine. In principle, an ORM can save developers from writing a lot of tedious code, speeding production of business applications.

EF in versions up to 6 (the current iteration) supports an XML-based model (stored in .edmx files) together with a diagramming tool for Visual Studio, Microsoft’s all-purpose development tool. Using the visual designer, you can design a database, complete with relationships and constraints, and then apply it to a database to generate the tables and other elements. You can also generate a diagram from an existing database.

The tool also supports a code first approach. In this scenario, you do not bother with a database diagram, but simply write classes representing the objects you want to store. You then reference these classes in a special class called a DbContext to have EF persist them to a database.

In a recent blog post Microsoft Program Manager Rowan Miller confirms that from EF 7, code first will be the only way to use EF. Miller adds that “code first” is a misnomer, since you can reverse engineer an existing database to make it a database-first solution.

Code first is a better approach, if only because it is simpler. If the system is maintaining an XML model, the database itself, and also a bunch of classes, there is more to go wrong. Plain text code is also easier to work with, for example in source code tools, diff tools (comparing two versions) and the like.

Microsoft also added a key feature to EF that is only available with code first, which is migrations. Migrations let you change your data classes and then update the database without losing data. However, currently only the old model-first method lets you go the other way, updating data classes from a changed database. Miller says something equivalent will be added to code first, but it is a delicate business, since the developer may have added code or comments to those classes that gets overwritten by an update.

The change does mean that the elaborate two-way database diagramming tool in Visual Studio will not work with EF7 (though EF6 will still be supported). It is one of many modelling tools to be introduced and later abandoned by Microsoft. This is bad news for developers who prefer to work with a diagram.

"We’re not kidding ourselves, it’s not possible to please everyone and we know that some folks are going to prefer the EF Designer and EDMX approach over code-based modelling," says Miller.

The snag with ORM tools, EF included, is that while they solve some problems, they introduce others. They can be less efficient than writing your own SQL, with a common problem being that the ORM tool may retrieve more data than the application actually needs for a specific operation, whereas a developer can request only the exact fields and rows that are required. The ORM layer can also be a black box that is hard to debug; you have to trace the SQL that it generates and puzzle out why it is wrong.

Some developers therefore prefer to avoid EF; but integration with other Microsoft frameworks like ASP.NET MVC means that avoiding it can also require some effort.

Performance, says Miller, is also a priority for EF7. He adds that the new release, likely to coincide with the next Visual Studio, is “part v7 and part v1”, which implies that some things may be a little rough in the first iteration. ®


Biting the hand that feeds IT © 1998–2017