One of the things in programming that you should get right the first time is code first models. Refactoring a database is way more work than normal code, and there will be cases where it’s so much work that it won’t be worth it.

So here’s a few tips from my recent (sometimes painful) refactoring work.

1. Don’t think about how your model will look as a table, too much. It is Entity Framework’s job to worry about that. You should be more worried about making models that will be useful in your code, that just happen to get stored in a database.
2. Keep it simple. Now that I said not to worry about what it will look like as a table, I’m going to somewhat reverse that and remind you that SQL doesn’t know what MyFoo is, so don’t use it in your models. Stick to the basic types that come with .NET.
3. Specify your table name now using the Table annotation on your model class. You may or may not like EF’s default way of naming tables so avoid surprises and name them yourself, now, before you create migrations. It’s really hard to rename a table after it’s been used.
4. Don’t overdo annotations. The useful ones are Table (see #3) and Required. There will be things in your model that will be required, but don’t go overboard with that. Every Required field will throw an exception if you forgot to put a value in it, and that particular exception happens in a weird place and it will take forever to figure out that you just forgot to put a value in MiddleName.
5. Don’t restrict your string field’s length, unless you have a really good reason. The database column will be something like NVARCHAR, meaning it will be as big as you need it to be. These are not the days of dBase where a 50 character string took 50 bytes of space, or where the maximum column width is a paltry 256 characters.
6. Inheritance is bad, in models. POCO’s seem like the perfect opportunity to go crazy with the perfect OO inheritance scheme. Don’t do it. Relations have a tendency to act up if one of the fields is an inherited field. You can implement interfaces, but don’t extend classes.
7. Give your model class a different name than models that exist elsewhere. It gets really confusing if you have two classes called Equipment. Sure, they’re in different namespaces, but it still gets confusing. It’s best not to pollute your EF models with weird names, so a more accepted standard is to change the outward facing models to be <something>ViewModel or <something>EditModel.
8. Don’t use the same model in your front end (be it web page or web api) that you use in the database. There will be a reason for them to be different, it’s just a matter of time. For example, if your tables have audit fields, like CreatedBy or ModifiedBy, it is a bad idea to pass those fields out of the system as you may be giving someone user id’s they could use against you.

I hope this list is helpful and that at least a few someones avoid headaches by using it. The list might grow over time. If you have an EF code model “gotcha” that I missed, put it in the comments for other people to see.