Entity structure with a large project

Question

My team and I are going to start a new project, and we are at the stage of studying and testing some new (or not very new) technologies.

Until today, we have used classic ADO with DBDataReaders, a proxy for lazy loading and, in some cases, DataTables.

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

Our new project has potential for growth, so we expect 100 tables.

I read and did some simple tests with EF5 for the past 2 days, and I still cannot decide if we should use it.

• Usually we divide a large project into many “modular” projects, which allows us to work faster and better under source control. Will we use one big "edmx" for the whole database?
• Since we have a database constructor, I suspect CodeFirst is not an option. So is it worth using EF using the Database First approach?
• If we use the first approach to the database, is EF smart enough to correctly identify all relationships and be ready to use without additional configuration by me? (Due to additional configurations, I mean that I will have to write DataAnnotations or use Obveride DbContext)
• Personally, I consider myself very confident in creating a database with sql. The only annoyance I have is when I have to update all the select, delete, update, insert scripts when the entity is changed in my list classes. EF will take care of this for me, but apart from this, I am starting to believe that it will slow down productivity and ultimately slow down my production, since we are not familiar with it.

Do you think THIS HAPPENED THIS?

* With the exception of DataAnnotations and Obveride DbContext, does anyone use simple T4 templates to create tables (schemas)?

Answer 1

I decided not to use EF. I am not going to risk using it in a large project.

All the work necessary to use it, the ability to deal with errors, additional overhead. I prefer to write more sql code and spend more time on maintenance than working with generated models or checking sql profiler for generated queries.

Thank you all for your comments ..

* Before moving on to direct ADO, I will take a picture of FluentData and Dapper. I will open a new question, so if you guys want to comment on these two bright ORMs, I will post the link later.

Answer 2

• I would recommend creating several models. You can choose which tables, views, and stored procedures should be displayed for each of them.
• The database is absolutely perfect at first.
• If database restrictions are set, EF recognizes them. You will not come across minor changes, but all of EF does a pretty good job.
• Using EF will have a small impact on query performance. But in most cases this is not a problem. In the few cases where you may have unacceptable performance, you can optimize by introducing your own SQL in EF, if necessary.

I think you will quickly become familiar with the use of EF, so I do not think that unfamiliarity will be a long time.

Answer 3

If your database structure is mature, EF should be a good solution for you.

If the database structure is being developed or will change over time, I would say that EF may not be the best for you.

EF needs to be updated when structural changes have occurred (and possibly database-level interface changes). You should think about how you will manage database changes in an already developed code base.