The landscape for accessing back-end databases in the Microsoft world has changed so many times over the last 20 or 30 years that those of us who have experienced it all tend to be both somewhat weary and somewhat cynical.
Back when C++ was the only comprehensive option for programming against Windows, and Visual Basic was still in its initial versions, there were no good options from which to choose. Programming against the database, any database, was painful because even simple things were not simple. I recall having to write 18 lines of code just to open a connection to a database with ODBC in the early 1990s.
Visual Basic 3 saw wide success precisely because it made simple database operations easy with the introduction of Data Access Objects (DAO). With DAO, you could build a bridge between your application UI and the back end that made it trivial to bind a textbox or label to a field in the database, and it would even update when the record pointer changed.
This was a major breakthrough in data binding that is now so far in our rearview mirror, but it took some time for the warts of this system to surface. Scalability was a major issue with DAO, so in the subsequent versions of Visual Basic, Remote Data Objects (RDO) was introduced as the data access technology designed to solve the problems with DAO.
While originally welcomed (especially by those needing access to remote back-end systems and seeking to leverage ODBC without having to deal with the ODBC API directly), RDO did not enjoy the widespread adoption and success of DAO. Developers widely rejected it for a lack of robustness in problem-solving, while it made programming harder in the process. This is certainly a common element in my experience: Tools that make things possible are much less likely to succeed than tools that make things possible and easy. For this reason, RDO turned out to be less a replacement for DAO and more an alternative that coexisted with DAO.
In October 1996, ActiveX Data Objects (ADO) was introduced, and it represented an improvement with its simple object model of a Connection, a Recordset and a Command. With these three objects we could rule over the database, and at the time it really felt like we had arrived. We had flexibility and simplicity; who could ask for anything more?
The short answer is that time kills all kind thoughts for any API, and ADO was not immune. Even though ADO unified the solutions provided by DAO and RDO while maintaining the “keep it simple” commandment, the disconnected model did not exist in ADO, and its time had come.
A few years later, enter ADO.NET and the addition of the DataSet. DataSets were (and are) custom-made to allow for disconnected scenarios, and for many years, ADO.NET was enough to get the job done. In 2008, when Microsoft introduced Entity Framework version 1.0, it was to a world that already thought it had the next evolution of data access technology in the form of LINQ.
LINQ (the Language Integrated Query) was introduced in 2007 as a language enhancement that provided native data querying capabilities to the .NET languages, and it was initially greeted as a game-changer. Up to this point, developers really were limited if they did not have a firm grasp on the relational database concepts and in particular the specifics as they related to the schema of the database being manipulated by the programs they were writing. LINQ allows developers to manipulate data without jumping outside their language. This was the first step to isolate the developer from the underlying SQL of the relational database while appropriating the power of the SQL language.
When Entity Framework 1.0 was first introduced, it met with strong resistance for two primary reasons. The first is that people were just ramping up on LINQ in its various flavors, and Entity Framework was seen as a competitor that could signal the end of support for LINQ tools. Given all the history just run through, you can see why developers were gun-shy about adopting a data access technology that was not going to be around for a long while. There was much gnashing of teeth when ADO rendered RDO obsolete, and this was seen as a possible repeat and, worse, a potential trend!
Second, it would be a vast understatement to say that Entity Framework 1.0 was not well received on technical grounds. In fact a very large number of well-known influencers in the technical community actually put forth and accumulated significant support for a “vote of no confidence” for Entity Framework 1.0. The message to Microsoft was either provide fixes for the issues, or forget about it and run with LINQ.
Ramping up for version 4.1
As we know now, Microsoft took a couple of years to address the issues and released Entity Framework 4.0. (Don’t bother looking for Entity Framework 2.0 or 3.0; those versions where skipped to put the data access technology version in sync with the underlying .NET Framework.) Entity Framework 4.0 made its debut with Visual Studio 2010 and the introduction of .NET Framework version 4.0.
With this new version, the problems seen with Entity Framework 1.0 have for the most part been addressed, and excitement for the technology has been mounting ever since. Microsoft in April released the 4.1 update to Entity Framework, almost exactly a year after the release of 4.0, and there is already another update on the horizon. For our purposes, we will mention some of the coming changes and new features, but the question is whether the current version of Entity Framework is the right choice if you were to start a project next week.
The answer to that is “probably.” This may be just the right time to jump in with Entity Framework now that we are effectively in the third version. I consider Entity Framework 4.1 to be effectively the third version, since 4.1 brings better tooling and 4.0 was a big improvement over 1.0. However, it is never my preference to simply adopt a new technology because the old one is expected to get no love from the tools vendor.
So what are the merits of the case for adopting Entity Framework? Relational Database concepts represent an area of expertise unto itself. In the face of having to program against a relational database (something every programmer has had to face with virtually every single project), you have to either dig into the relational model and adjust what you want to do with how the data will ultimately sit in the database, or you can seek to abstract away the relational model in a way that lets you remain blissfully ignorant of what lies beneath.
For many years, Stored Procedures played the primary role in this second strategy. They had the benefit of being reusable and they also added security to the system, since the database admin could give developers just the views and stored procedures that they need to get the job done without giving them access to the entire database. This meant that the developers were often highly dependent on the database admins, and this often results in a bottleneck and much back-and-forth. It is only natural that the development community would continue to look for alternatives to this approach, and so Object-Relational Mapping (ORM) evolved as a best-of-both-worlds solution. Basically the philosophy is, if you can’t beat them, abstract them.
The role of the ORM tool is to shape the data model you have into the object model you want or need. Up until now, data access technologies provided by Microsoft have just concentrated on allowing developers access to the underlying data, with the bells and whistles mostly pertaining to data binding with interface elements like text boxes, grids and labels. The move to make the data access technology (in this case Entity Framework) also an abstraction layer is an escalation and a bit of a revolution. To be honest, I still have my reservations since I am definitely one of those developers who think in terms of the underlying relational model, given that most of the time I was involved as an architect in designing that relational database.
The majority of developers, though, do not relish exploring a good relational model and then adapting to it. These people often also have lives, which I am told can be quite rewarding (just kidding).
Ultimately, given how complex things seem to be getting with time, it seems a reasonable step to have the data access technology help the developer by bending the object model to their purposes rather than forcing the developer to shape their code to the underlying data. Once you get past the question of whether you are willing to use an ORM tool, you can get into the features and benefits of the Entity Framework.
