When the first version of Entity Framework came out, I really liked the concept but felt that it lacked too much to be a real-world solution. However, with the relatively recent release of Entity Framework 4 (EF4) I think it has reached a point where serious consideration should be paid to using it as an object-relational mapping (ORM) framework for your applications.
We have an existing system that makes use of LINQ to SQL for its database connectivity, and we ‘translate’ the objects into real business objects that we use through our tiers. However, we have known about the impending doom of LINQ to SQL for a while now:
We also have a client that REALLY wants to make use of their existing Oracle infrastructure, and hence the database agnostic approach that ‘is possible’ in EF4 becomes really appealing to us developers that do not really want to worry about the intricacies of Oracle. As well as the following two third-party providers:
Oracle themselves are getting behind this technology with a Statement of Direction released in June 2010.
So, given we have a ‘supportive’ client, we are able to justify replacing LINQ to SQL and our current business objects with EF4 to achieve the client’s goal of using Oracle and our desire to migrate to current technology.
My first impressions were that it’s a big improvement over the first version! I love Model First; it’s a very natural way to develop.
However, in my current scenario it was decided that it was easier/quicker to make use of the existing database schema than starting from scratch as we have an existing client base with real data, etc. But, you should consider the limitations that exist in both EF4 and your existing database schema to make a proper determination of what’s appropriate for your own scenario…as it may be quicker/easier to start from scratch than trying to ‘map’ what you currently have.
Having a central model that multiple applications can ‘feed off’ rather than the DB schema itself is also fantastic! The use of T4 code generation provides us with lots of scope/power to enhance/fix, etc. In our particular solution, we have a WCF client, a web application and a reporting application: these can all use the same model…we can generate specific objects from the model that are appropriate to the specific application, e.g. for the reporting application we may want to keep things nice and simple and just use POCO, whereas with WCF we can generate Self-Tracking Entities.
All of this can exist under TFS, we can share and avoid redundancy far easier than is possible with our current solution.
So overall, I’m positive about the technology. If you are also taking those initial steps into using this technology, I’d strongly recommend watching Julie Lerman s introductory videos, and also grabbing the following books:-
BTW Many thanks to both Zeeshan Hirani and Julie Lerman for their patience and feedback!
Given that I’ve ended up writing so much above – sorry; got carried away - I will post discrete entries on some of the aspects of this technology that have bitten me in the hope it saves other developers time that I wasted. Most issues thus far hinge around limitations with inheritance…
| posted on Friday, 13 August 2010 1:04 PM