EF Model First or Code First Approach?

Question

I know this question has been asked numerous times before as I’ve read quite a few posts on the topic about the pros and cons etc but I still can’t decide which approach is

Answer 1

This is too long question. You should break your problem into multiple separate questions next time.

Code-first x Model-first x Database-first

You are a database guy so the best approach for you is an incremental database-first approach where you define the stuff in DB (or VS Database tools) and update your model from the database. This will give you a big control over your database and allow you building the application and the DB incrementally. Why I think you will like it:

• You did SQL DB Admin before - you probably know something about DB and how to design them for a performance - EF will not do anything from this for you. EF will not create indexes for you etc.
• 30-40 tables means that you will not build the model in one shoot. You will start with the small model and continuously grow it. Once you start making changes in DB or adding initialization data you will not want to lose these changes and the data. Code-first allows only deleting the whole database and recreating it from scratch. Model-first allow building the DB incrementally but you need Entity Designer Database Generation Power pack and VS 2010 Premium or Ultimate ($5.000-$10.000).

More about differences between DB first, Model first and Code first. Another answer describes differences between code-first and working with designer.

DbContext API + Database-first + Fluent mapping

I would call this the hardest way to go. You will the define database first and you will use DbContext fluent API or data annotations to define mapping. This requires good understanding of EF and all principles behind the mapping + understanding of default convention used in DbContext API. It will give you nice and explicit control over mapping but it is the most work to do. It is definitely the hardest way to go. Also it is not supposed usage because DbContext API was primarily created for code-first approach.

DbContext API x ObjectContext API

Once you start using EDMX (entity designer) you have a choice to use either DbContext Generator T4 template or POCO Generator T4 template. Decision is up to you - you can use either DbContext API (first template) or ObjectContext API (second template) which is much better documented and you can also use two great books:

• Programming Entity Framework
• Entity Framework Recepies

All I know about ObjectContext API is from these books, authors' blogs and practice + Reflector.

DbContext API doesn't currently have any book. You can check some main sites to get info about it:

• ADO.NET Team blog
• Julia Lerman's blog
• Morteza Manavi's blog

All I know about DbContext API is from these blogs and practice + Reflector.

Even if you are using code first you can still use class diagram to visualize your class diagram (it is not the same as EDMX but it is enough for getting the big picture).

Searching on Stack Overflow or MSDN forum will give you answers on most problems you will have with both APIs.

MVC 3

There is nothing specific with using entity framework with MVC 3. Buddy classes for data validation annotations are considered bad practice. A buddy class is separate class used as a metadata holder applied on the entity. A view model is the class used to transfer data between controller and view. View model should be specific per view with its own validation annotations because you usually need different validations in different screens of your application when working with the same entity type - for example edit and insert screen can have different validation requirements.

Despite the fact it is not considered as the good practice, adding validation to entities is possible - you can either create buddy class for each your entity manually or you can try to modify T4 template to generate annotations for you directly (well this is hard).

One-to-one relation

Yes EF requires creating one-to-one relation only on top of primary keys. The reason is that EF doesn't support unique keys / constraints. There is no way around this and using unique keys in database will not change it.