Entity Framework with a Large Project [closed]

Question

Me and my team are going to start a new Project and we are at the stage of exploring and testing some new (or not so new) technologies.

Till today we were using classic ADO with DBDataReaders, proxies for lazy loading and in some cases DataTables.

The team consists of 3 developers and one Database designer. Our projects consists at least 130 tables each.

Our new project has the potential to grow so we expect 100 tables for sure.

I have been reading and doing some simple testing with EF5 the last 2 days and i still can't decide if we should use it.

1. We usually split a big Project into many "module" projects allowing us to work faster and better under source control. Are we going to use one big "edmx" for the whole DB?
2. Since we have a Database Designer i suspect that CodeFirst is not an option.. So is it worth to use EF with the Database First approach?
3. If we use the Database first approach is the EF smart enough to detect all the relationships correctly and be ready for usage with no more additional configuration by me? (By extra configurations i mean i will have to write DataAnnotations or have to ovveride the DbContext)
4. Personally i find my self very confident about designing a Database with sql. The only annoyance i have is when i have to update all of the select, delete, update, insert scripts when an entity is changed in my classes-Lists. EF will take care this for me but except this i'm starting to believe that it will slow down the performance and eventually slow down my production since we are not familiar with it..

What do you think IS IT WORTH IT ?

*Except the DataAnnotations and the DbContext ovveride, is anyone using plain T4 templates to create the tables(schema)?

Answer 1

1. I'd absolutely recommend to create multiple models. You can select which tables, views, and stored procedures to map for each.
2. Database first is absolutely fine.
3. If the database constraints have been set then EF will recognize them. You won't get around minor modifications, but all in all EF does a pretty good job.
4. Using EF will have a slight impact on query performance. But in most cases that won't be an issue. In the few cases where you may have an unacceptable performance hit, you can optimize by injecting your own SQL into EF where necessary.

I think, you'll become familiar with the usage of EF pretty quickly, therefore I don't think unfamiliarity will be an issue for long.