With the availability of Visual Studio 2010 BETA 2 for developing production code, we can finally say Goodbye to Entity Framework 3.5.
I was/am very new to the ORM arena. I spent like 2 months on and off to do some work with EF and to develop some applications and I have had some good and frustrating experiences with this. I wanted to put together some of these here.
Things I liked :)
- I was pretty amazed at how much Data access code is lessened by adopting this framework. Database tables are represented as entities and are regular C# classes and working with them was pretty easy.
- All the SQL commands are handled by the framework which could be good and bad depending upon the situation you are in. Since it takes care of generating the SQL statements for you for retrieving the data or persisting the data, this could aid in Rapid Application Development. But at the same time, you are giving away the control you had to develop the SQLs the way you wanted it.
- Framework along with the Visual Studio designer providers excellent view of the entities and their relations. You can add or update or remove the tables from the model (Entity Data Model) and the corresponding code behind is generated for you.
- Framework provides a good implementation of the Unit of work pattern for your application code. You can defer all the database operations until the ObjectContext SaveChanges() is called.
Things I did not like :(
In spite of all these advantages, I did suffer from some issues in adopting this effectively in my application development.
- Lately, I have become a big fan of unit testing and TDD. Entity Framework 3.5 does not help with effective unit testing by using mocking. So, this was quite frustrating to deal with. TypeMock allows you to mock classes without interfaces, but it is a commercial product and is little pricy for me.
- There is no support for using POCO classes for entity development. So extending the framework generated classes is not very elegant. All the classes generated by framework are decorated with partial class keyword, this provides an opportunity to add our own code in your code files. But this approach becomes very ugly very soon if you are extending lot of entities.
Most frustrating factor of all is that I could not settle down with one good code architecture. I considered various levels of separation between the business code and the entity framework code and each one showed its own ugly face.
- The first pattern was Business and data access are complete separated. DAL layer would completely encapsulate the framework. Data access components exposed interfaces that business layer can call.
- Business Layer had a set of entities to manage the business needs.
- Data access layers had entities generated by the framework
- The data transfer between these layers were happening using DTOs which looked like entities themselves.
- I had so much similar looking code among these three components that I was spending more time managing them. (My business entities looks like my data access entities, unfortunately)
- Managing transactions was an issue too as the transactions was maintained by the DAL layer. I did not wanted to use TransactionScope as it will affect my application performance.
- The second pattern was to mix the business and data access and use the framework generated entities as my business entities also. Though this looked like a good approach in the beginning, I soon realized that the boundary between the business and data access had completely vanished. If I had to replace the entity framework in future (oops), I have to redo everything and it violated the golden rule of separation of concerns
- The third approach was to have minimal framework code in the business layer. ObjectContext creation, handling transactions (using EntityConnection) can be handled within the Business layer very easily and had the potential to become very satisfactory code architecture to use. But the above mentioned limitations (unit testability, extending entities) will not give you sense of peace.
These kinds of concerns have already made it to the list on the Vote of No Confidence. Take a look at this list.
We now have a new version of Entity Framework in .Net 4.0 which is going to address my concerns and I am now trying to give it a spin and I like whatever I have seen so far. It has POCO support and was developed with testability in mind. I will write up more on the new version later on.
With the availability of this version, I can safely say goodbye to Entity Framework 3.5 and say hello to 4.0.
Here are the great blogs that have helped me to get answers I needed on all of these
Namaskara,
Harsha
No comments:
Post a Comment