QandA: Is the ADO.NET Entity Data Model designer fixed in .NET 4?

  • Article

[I haven’t done QandAs for a long while – very remiss of me.]

Anyway, I have been asked this one so many times lately that I felt a more public answer was needed.

The short answer is: Mostly. Certainly it is good enough to get work done.

The longer answer is below…

History

In the first version of Entity Framework (which came with .NET Framework 3.5 SP1), the Entity Framework Designer was… bad. I mean very bad. I mean dumbly bad. We had a decent enough runtime but the design surface just wasn’t up to the job, instead hiding away much of the capabilities of the Entity Framework as well as just poorly supporting the lifecycle of an EDM.

Many folks needed to either directly edit the underlying xml file (.edmx) or switch to their own tooling or alternative products such as the Devart Entity Developer. This was a huge shame and IMHO (and in my experience) the designer proved to be a huge factor in turning some folks away from the Entity Framework.

Hence, we have waited with crossed fingers to see what Visual Studio 2010 brings.

Visual Studio 2010 Beta 2 brought us…

Well, at first glance it brought us the same designer… because it is fundamentally the same designer.

But this time around the team have had a chance to:

  • Remove most of the rough edges
  • Add functionality into the designer to support more of the capabilities of the runtime

There is a lot of good improvements in the designer such as support for Model First, Complex Types, Templated code gen, Stored Procedure, Pluralization/Singularization plus much improved search and delete capabilities. (Check out the appropriate section of my  https://bit.ly/ef4resources list).

However, there are still (as of Beta 2) many missing capabilities in the designer including

  • Multiple entity sets per type.
  • Creating entity sets for non-root types.
  • Table-per-concrete class mapping.
  • Using EntityType properties in mapping conditions.
  • Unmapped abstract types. When you create an abstract entity type with the Entity Designer, the type must be mapped to a table or view.
  • Creating conditions on association mappings.
  • Mapping associations directly to stored procedures. Mapping many-to-many associations is not supported. You can indirectly map other associations to stored procedures along with entity types by mapping the appropriate navigation properties to stored procedure parameters.
  • Creating conditions on Function Import mappings.
  • Annotations.
  • Query views.
  • Models that contain references to other models.
  • Creating associations without corresponding navigation properties.
  • Adding or editing storage model objects. (Deleting storage model objects is supported.)
  • Adding, editing, or deleting functions that are defined in the conceptual model.

The above list is pulled straight from the documentation. In some ways it is a list that actually reflects just how powerful the runtime now is, however that can not disguise the fact that the designer is still playing catch-up with the runtime.

I would add to the above the following none exhaustive list:

  • “Odd” way of working with complex types across Entities
  • Model First requiring a database connection
  • Model First not allowing mapping before first schema gen
  • Model First is destructive on generate
  • Lack of support for very large models/schemas
  • Lack of versioning support
  • Lack of support for team development of a model
  • Lack of granularity of operations e.g. just re-generate the mapping of a single entity (or exclude an entity)

Overall, the designer in .NET 4 is a welcome improvement to what we get in v1 and is certainly now a useful tool for working with EDMs. But… there is still plenty of room for improvement.