EF Model First or Code First Approach?
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 right for me. I’m very new to web programming and come from a SQL DB Admin / report writing background. I’ve decided to try build my own website which may end up having 30 -40 tables maybe more in the future.
I’ve looked at both approaches and I do favour Entity Model approach only because I like simplicity of the designer and I like seeing the whole model in front me, it shows the overall picture in one snapshot. Also, me not being a strong programmer I am impressed with the way it generates the POCO’s using the DbContext generator template and does all the linking between the classes.
However, although I like the Model First Approach I feel there are some draw backs, I’m not sure if they are actual drawbacks or I just don’t know enough about the model first approach and code first approach as I’m still very new to this.
The Reasons that I am hesitant to use the Model First approach are:
-Mainly because I am struggling to find tutorials on the Model first approach using MVC 3. The best tutorial I’ve found using the DbContext is by Julie Lerman but she doesn’t cover buddy classes which are important for using data annotations and making other changes that aren’t lost when you regenerate the POCOs . Most tutorials MVC 3 related seem to use the Code first approach. Most people say this is because the tutor doesn’t want to focus on EF but rather show more MVC in the tuts. I personally think it’s because Microsoft is championing the Code First methodology over the others :)
-If it’s good practice to create buddy classes why can’t I find many tutorials showing this for MVC 3? Are Buddy Classes another name for View Models? And why can’t I find any tutorials by Microsoft showing these buddy/view models in use with MVC 3?
-I was trying to do a basic 1 to 1 relationship between 2 tables. In model first you have to set the identity keys of each table to the same field rather than using a FK in one of the tables, which may get a little confusing when you have 3 or more tables linked to each other by 1 to 1 relationships. In code first a way around this is use the model builder and set it up manually. I think in MF you can change the relationship by going into the XML which I am not keen on doing at all.
-More support/help on code first problems
The reasons I am hesitant to use the Code First approach are:
-I’m a novice coder.
-I see it getting quite difficult to keep track of tables and relationships as the project expands.
-There is no Model diagram and I have to say I really do like this idea.
-Mapping entities to the database via configuration classes I find impossible :).
-Updating a table will require a change to the code and the DB. In Model first only one change to the model which will automatically update the DB and Code having said that if you’re using buddy classes you may have to update these as well.
Also now I see people are somewhat combining Code First and Database first approaches, in that you don’t let Code First generate your database but manually create a database and use code first API to EF to get to it.
My head is spinning with all the options and drawbacks and pros and cons. I just want to get on with creating my website and not ponder on which approach to take. Can anyone give me some insight on which approach they think is best based on what I’ve said and/or what they think will be more main stream in the future?
Many thanks dave
Answer
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:
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:
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.