Tuesday, 23 April 2013
Last time, I wrote that I'd decided it was time to update our software and make use of technologies that have been more recently released than those we'd been working with over the past few years. One of those technologies is the Entity Framework.
When we first started work on ConvallisCRM the Entity Framework was still in development and hadn't been released, but what had been released was a tool called Linq to SQL. Both of these technologies are examples of what are known as object relational mapping tools, or ORM for short.
In our daily lives we make use of various objects on a daily basis, from the telephone to communicate with others to our beds in which we sleep. In a similar fashion many programming languages allow us to define and create 'objects' that represent a function or data within an application. An ORM is a tool that performs a query on a database and maps those results into a data object within the application that can then be further manipulated, oft times that simply means that it is displayed.
The first version of ConvallisCRM made use of Linq to SQL as its ORM come data access tool, this was in preference to an older technology that I'd used up until then. Linq to SQL certainly proved to be an asset and well worth the effort to learn and use. But there was a problem, with the release of the first version of Entity Framework and the subsequent release of Visual Studio 2010 Microsoft announced that they would not be working on Linq to SQL going forwards. The reason given was simple, Linq to SQL was designed for use only with SQL Server and could not be used with other database technologies, whilst Entity Framework was designed to be used with any database as the store.
That left with me with a dilemma, do I stick with Linq to SQL or switch to Entity Framework? Back when I wrote ConvallisCRM version 2 I decided to bite the bullet and switch to Entity Framework. It wasn't as much work as I anticipated it would be, and hasn't been a decision I've regretted as it has provided us with a strong foundation for our data access in ConvallisCRM.
Last year it was announced that the team developing the Entity Framework would become part of the ASP.Net team which would start releasing enhancements to ASP.Net more often than the bi-annual release cycle we've had up until now. As if to underline that decision the latest version of Entity Framework (version 5) wasn't released at the same time as Visual Studio 2012, but was instead released a few weeks later.
So as I start thinking about the next version of ConvallisCRM and the projects we are working on, I found myself with yet another decision to make regarding our data access tools. Do I stick with the version of Entity Framework I was using or switch to the latest version which would require some conversion work?
I decided to make the switch, it wasn't a difficult decision. The unfortunate side effect of using first Linq to SQL and then early versions of Entity Framework was that our data objects were quite 'heavy'. They didn't only represent our data but also included 'baggage' that was specific to the ORM, and because they were generated automatically included default configurations that were out of my control.
Whilst with EF 5 we can stick with the older 'heavy' data objects, it also provides the capability to generate much 'leaner' data objects that are generated to our own requirements thanks to a built-in templating technology that also allows me to make changes to the templates. This technology allows us to create plain data objects that don't include any of the ORMs baggage.
Even though these days we have faster connection speeds, it is still important to keep the data that we might send across the network or the internet as small as possible. So in some ways it was a no brainer as being able to generate data objects with none of the ORM baggage means that the data we send across the network would be smaller and hence be delivered faster. I also like the fact that I am in control of what is generated thanks to the templates.