Question

We currently have a solution that was completely written by hand in ASP.NET and MVC.

There are a lot of ugly hacks and workarounds in the DAL currently and rather than expand on these hacks, I’ve managed to convince the suits that we need to migrate to an ORM of some sort.

With Entity Framework experience in the team, we’ve decided to go with the Entity Framework, however, I have a migration question for anyone who may have had an experience with this.

Would there be any performance issues if we were to migrate Entity-by-Entity until everything was migrated to EF? What possible roadblocks (other than the obvious of having to rewrite most of the BL) could we face? Should it literally be done Entity-by-Entity (in terms of, creating the models) or would there be issues creating the entity model and just changing the BL bit-by-bit.

I can’t seem to find any documentation on the subject.. MSDN seems to just say “Yay Entity Framework is good, so migrating to it is good.”.

Any advice would be appreciated.

PS: I did read this: Migrating from 'native' OODBMS to ORM (Entity Framework / SQL Server)

However as we’ve decided to go with EF instead of NHibernate, it didn’t prove very useful.

Answer 1

It’s good question and i have a answer from my prospective. It’s about ‘Yay Entity Framework is good, so migrating to it is good’

Now our team is working over big (very big) HR SaaS solution. From the beginning we decided to use:

• EF 4.1
• MySQL (that was requirement from client)
• .NET MVC 3

Then time passed (near 3 weeks) we noticed next about EF: using Model first is not applicable and useful in our system in case of hard to support system in future when we need, for example, change a little bit db structure or make new relations between tables.

In this case we moved to EF Code First (with one generic repository for all db requests). That was the risk cause it’s so new technology and there was no best practices or use cases on big solutions. As result we recived a lot of other headache:

• ORM made a lot of db requests (cause of a lot of relations between tables). Fixed by .Include()
• Dynamic Proxy for POCO objects – made a lot of troubles, cause in code first entities from db came not like requested entity type – like dynamic proxy type. So when we tried to serialize them and put to Memcached on deserialization we get the error that this entity no more available in current context. Fixed like this: http://msdn.microsoft.com/en-us/library/dd456853.aspx and this: http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
• Stupid bag with Membership that sent a lot of unbelievable requests. Fixed by reviewing our work with Membership

Also we tried NHibernate to just compare performance. NHiberanate has the same 🙂

General info that you should know about EF:

• If you want to attache 3rd part caching be ready for workaround. NHibernate have a native integration of this
• There is no big different between EF and Nh performance, but Nh have a lot of hand work with mapping

Hope i answer to your questing and info is relevant for you.

ps> sorry for my English 🙂