Let’s now look at a few ways we can use the OnModelCreating
method to customize the database persistence of our models. We will begin
by looking at a pretty common scenario – where we want to map a model class to
a database schema whose table names are different than the classes we want to
map them to.
For example, let’s assume our database uses a pattern where
a “tbl” prefix is appended to the table names. And so instead of a
“Dinners” table we have a “tblDinners” table in the database:
We want to still map our clean “Dinners” model class to this
“tblDinners” table – and do so without having to decorate it with any data
We can achieve this custom persistence mapping by overriding
the “OnModelCreating” method within our NerdDinners context class, and specify
a custom mapping rule within it like so:
The code within our OnModelCreating() method above uses a Fluent API
design – which is a style of API design that employs method chaining to create
more fluid and readable code. We are using the ModelBuilder object to
indicate that we want to map the “Dinner” class to the “tblDinners”
And that is all the code we need to write. Now our
application will use the “tblDinners” table instead of the “Dinners” table
anytime it queries or saves Dinner objects. We did not have to update our
Dinner or RSVP model classes at all to achieve this – they will continue to be
pure POCO objects with no persistence knowledge.
Trying out the Above Change
If you downloaded the completed NerdDinner sample from my previous
blog post, you can modify it to include the above custom OnModelCreating()
method and then re-run it to see the custom database persistence in action.
We enabled the automatic database creation/recreation
feature within EF “code-only” with the previous blog post. This means
that when you re-run the downloaded NerdDinner application immediately after
making the above OnModelCreating() code change, you’ll notice that the SQL CE
database is updated to have a “tblDinners” table instead of a “Dinners” table.
This is because EF detected that our model structure changed, and so re-created
the database to match our model structure. It honored our custom
OnModelCreating() mapping rule when it updated it – which is why the table is
now “tblDinners” instead of “Dinners”.
Several people asked me at the end of my first blog post
whether there was a way to avoid having EF auto-create the database for
you. I apparently didn’t make it clear enough that the auto-database
creation/recreation support is an option you must enable (and doesn’t always
happen). You can always explicitly create your database however you want
(using code, .sql deployment script, a SQL admin tool, etc) and just point your
connection string at it – in which case EF won’t ever modify or create database
I showed the auto-database creation feature in the first
blog post mostly because I find it a useful feature to take advantage of in the
early stages of a new project. It is definitely not required, and many
people will choose to never use it.
Importantly we did not have to change any of the code within
the Controllers or Views of our ASP.NET MVC application. Because our
“Dinner” class did not change they were completely unaffected by the database