Where we are at present

For many of us the Entity Framework has made working with databases a great deal easier, especially in situations where we might wish to use the same database in numerous applications. This isn’t the place to go into a detailed history of the Entity Framework but there are a couple of points worth noting. Until the last release, Entity Framework had been an integral part of the .Net Framework. This proved to be both a blessing (if you had the .Net Framework (v4.0 +) installed then you had the Entity Framework) and a curse (any improvements to the Entity Framework were inextricably tied to release cycles of the .Net Framework itself). Now Entity Framework is released through NuGet and the core components of it have been separated out from the .Net Framework. It has also become Open Source (although very much overseen by the Microsoft development team). ComponentOne Studio for Entity Framework first saw the light of day in the early part of 2011 with its official release coming in November of that year. It worked seamlessly with the strongly typed models based on the ObjectContext that the ADO Entity Model Generator in Visual Studio 2010 produced. Combined with ComponentOne’s existing LiveLinq (Linq on steroids) it provided significant enhancements over the plain vanilla Entity Framework tools (such as they were) that Microsoft had produced. Indeed it was possible to produce a workable data based application with very little written code. Visual Studio 2012 brought with it a new version of the .Net Framework (4.5), Entity Framework itself progressed to Version 5.0 providing, amongst other things, Enum support and its first manifestation as a NuGet package (although it was still firmly rooted in the .Net Framework). It also bought with it the first move to generating Entity Models based on the DbContext. For those of us who had now grown used to using the Studio for Entity Framework, this was a nuisance because the DbContext entity Models couldn’t be used by the C1DataSource control. Fortunately Microsoft had not shut the door entirely on ObjectContext based models and there was a viable workaround which has been document in a previous blog post, which you can still refer to. Meanwhile in a far off place someone at Microsoft has decided to give Visual Studio development a kick-start. Out went the two year release cycle, in came a new one year cycle with more regular updates in between. The decision to separate the Entity Framework from the .Net Framework had by then been taken so that by the time that EF 6.0 arrived (ironically more or less in conjunction with vs 2013) it was a NuGet package with the emphasis very firmly on DbContext. ComponentOne meanwhile had moved to amalgamate the Studio for Entity Framework into the various platform studios to which it was applicable renaming it the C1DataSource. Visual Studio 2013 proved to be something of a problem for the C1DataSource. It neither sat well with the new version of Entity Framework and models based on the DbContext simply wouldn’t work with it; on the face of it, it would appear that the C1DataSource had reached the end of its life. Of course this hadn’t been the intention. ComponentOne has a justifiably envious reputation for supporting its products long after their apparent usefulness may seem to have passed (who else for example continues to support active x controls). The problem centered on a desire to continue to support data models based on both the ObjectContext and those that Visual Studio was now producing on the DbContext. By March of 2014 the problems had more or less been resolved and a version of the C1DataSorce was ready for testing. The new C1DataSource control needed to work with the latest Entity models produced by Visual Studio 2013, it needed to support EF6.x and above and it needed to provide a way for models that were currently in production environments to be upgraded to EF6.x and still continue to work as they did. The astute amongst you will have noticed by now that no mention has been made of compatibility with previous iterations of the Entity Framework quite simply because it isn’t. From now on the C1DataSource is intended to be used solely against EF6.x and greater. Existing models built against earlier versions of the Entity Framework will need to be upgraded.

DbContext vs ObjectContext

The other area of change in the Entity Framework has been the emphasis that is now been placed on working with the DbContext as opposed to the ObjectContext. It is worth digressing just temporarily and explain the basic difference between the two. If you think of the EntityFramework as an inverted triangle then the ObjectContext would fill all of it. It provides complete access to all of the various parts of the Entity Framework. DbContext on the other would fill the bottom third, providing access to the most commonly used parts of the Entity Framework. DbContext is perceived as providing a simpler way to interact with the Entity Framework and certainly the emphasis on development is centered on the DbContext. In truth this was all put somewhat better in Julie Lerman’s book on the DbContext. In her introduction to the DbContext she says:

Since its first release, the most critical element in Entity Framework has been the ObjectContext. It is this class that allows us to interact with a database using a conceptual model. The context lets us express and execute queries, track changes to objects and persist those changes back to the database. The ObjectContext class interacts with other important Entity Framework classes such as the ObjectSet, which enables set operations on our entities in memory, and ObjectQuery, which is the brains behind executing queries. All of these classes are replete with features and functionality - some of it complex and much of it only necessary in special cases. After two iterations of Entity Framework (in .Net3.5 SP1 and .Net4) it was clear that developers were most commonly using a subset of the features, and unfortunately, some of the tasks we needed to do most frequently were difficult to discover and code. Recognising this the Entity Framework team set out to make it easier for developers to access the most frequently used patterns for working with objects with Entity Framework. Their solution was a new set of classes that encapsulate this subset of ObjectContext features. These new classes use ObjectContext behind the scenes, but developers can work with them without having to tangle with the ObjectContext unless they specifically use some of the more advanced features. The new set of classes was originally released as part of Entity Framework 4.1 (EF 4.1). The prominent classes in this simplified API surface are the DbContext, DbSet and DbQuery. The entire package of new logic is referred to as the DbContext API. The new API contains more than just the DbContext class, but it is the DbContext that orchestrates all of the new features.

The emphasis being placed on the new DbContext means that the C1DataSource needed to be able to use it.

The new C1DataSource Control

In the May 2014 update, the new C1DataSource has been officially released. In this first release it will be for use purely in applications that target the WinForms platform. Support for WPF will follow with the second trimester release in late July 2014. It will support EF6.x only in projects targeting the .Net Framework 4.5 and above. This in turn means that it will only work in Visual Studio 2012 and 2013. If as seems likely there will be a new version of Visual Studio released in the autumn then it should work in that as well unless there are significant changes but it would appear that the Visual Studio team are now working on a continually evolving model rather than one that sees radical change every couple of years. As well as the C1DataSource control itself two new text transformation templates will be added to Visual Studio during the installation routine for the C1DataSource. These are "ComponentOne EF 6.x DbContext Code Generation Templates," one each for projects using C# or VB.Net and these will be added to each version of Visual Studio that the C1DataSource supports. The purpose of these templates is to ensure that the DbContext models that you create provide entities that support INotifyPropertyChanged. The template that currently ships with Visual Studio doesn’t do this and as such the things that you have come to expect the C1DataSource to do with ease (such as seamless master-detail grids for example) wouldn’t be possible. It would also make the use of live views with LiveLinq impossible if they weren’t there.

Where do we go now?

In my next post, we will walk through using the C1DataSource component in a new WinForms project. http://our.componentone.com/2014/05/20/using-c1datasource-in-a-new-project/ If you want to provide your ideas for things that you would like to see then we’d like to hear from you. The best place to do this is on the ComponentOne forums. Initially we’d suggest that you use the forum dedicated to the C1DataSource in the WinForms section (http://our.componentone.com/groups/forum/winforms/entity-framework-datasource/) where you can also ask any specific questions that you might have about the C1DataSource and its use in your projects.