We are always investigating new technologies to see if they
could improve our developers' productivity when developing a new
system, improve the maintainability of a system or enable us to add
functionality to the systems that we develop with minimum
effort.
When Microsoft released version 3.5 of the .NET framework, along
with Visual Studio 2008, they included a new data access technology
called LINQ. This technology is their Language Integrated Query
capability. LINQ allows a developer to query lots of different data
sources with the minimum code. This was certainly interesting to us
as we are always looking for technologies that allow us to do more
with less effort, thus providing more value to our customers. The
part of LINQ that communications with SQL databases, LINQ to SQL,
is similar to the data access technology that we currently use
very, NHibernate. Both provide Object-Relational Mapping (ORM[1]) functionality.
ORM allows our developers to work with data coming from a database
in an Object-Oriented way, making them more productive and the
systems we produce better structured and more maintainable.
While one team at Microsoft were developing LINQ, another team
were developing the Entity Framework. The Entity Framework was not
production ready when .NET 3.5 came out and was released with the
first service pack to .NET 3.5. There is a large overlap with the
functionality between the Entity Framework and LINQ to SQL, as both
provide an ORM facility. LINQ to SQL is aimed at getting developers
working quickly with Microsoft SQL Server databases, while the
Entity Framework has much more flexibility for mapping objects in
code to different data structures. This created some confusion for
developers as Microsoft were effectively pushing two different
technologies that provide the same function. This concern has been
resolved by Microsoft[2] and LINQ to SQL has
been effectively deprecated in favour of the Entity Framework. This
does not affect any other aspects of LINQ, e.g. LINQ to XML is
still going to be developed going forwards and in fact there is a
LINQ provider to the Entity Framework so developers can write LINQ
queries in their code that use the Entity Framework for data
access. Microsoft's clarification made it clear that our
investigation work should focus on the Entity Framework.
The Entity Framework brings with it a number of benefits, which
make it an attractive technology that we would be interested in
using. The Entity Framework comes with .NET 3.5 SP1 so there is no
separate download that has to be deployed to servers. This also
means that in future .NET developers will be more likely to have
familiarity with this technology. The tools available to work with
the Entity Framework are built in to Visual Studio 2008 so managing
the data objects in a project will be an easier process. The Entity
Framework is actually structured in a very similar way to
NHibernate. This means that the learning curve to get our
developers up to speed with the new technology will be quite small.
The Entity Framework has also been developed from the ground up to
support other database systems, rather than just MS SQL Server.
LINQ to SQL can be used with other database systems but this
appears to be an afterthought in the design process. The Entity
Framework was designed from the start to work with several
different database systems. This is very important to us as we
often work with Oracle as well as SQL Server and having a common
data access technology that all our developers understand aids
supportability.
All the available information looks very positive. The Entity
Framework would be a great fit with our development process, providing our
developers with productivity gains and helping with maintainability
of the systems that we write. Our investigation into the Entity
Framework has uncovered a number of problems however. Most of the
problems that we have come up against are related to the fact that
the entities created by default by the Entity Framework tools are
too closely coupled with the Entity Framework itself. This close
relationship means that we'd have to structure our applications in
such a way as would constrain our developers too much. Writing
n-tier applications would require significant amounts of code and
place considerable constraints on what our developers could do.
This would certainly not improve our developers' productivity or
improve maintainability of the systems we create as the problems
that we have discovered in our investigation of the Entity
Framework are not ones that we currently experience using
NHibernate.
We have had to come to the conclusion that although on paper the
Entity Framework looks very good, in practice we would not see any
benefits over using NHibernate for our data access. It would
constrain our developers considerably and ultimately increase the
cost of developing and maintaining a system. Fortunately, Microsoft
are aware of these shortcomings and it looks like Microsoft have
put considerable effort into the next version of the Entity
Framework that would resolve the majority of our issues with it.
Once version 4[3] of the Entity Framework,
included with .NET 4.0 and Visual Studio 2010, has been released we
will again look at this technology to see if it would provide us
with the productivity benefits that we are looking for.
[1] http://en.wikipedia.org/wiki/Object-relational_mapping
[2]
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
[3] Actually the second version of the
Entity Framework, but numbered version 4 to be in sync with the
version of the .NET framework that it is released with.