LearnNowOnline

Blog

Domain Centric Modeling - Microsoft SQL Server 2012

Excerpt by Don Kiely | December 09, 2013

When the first version of Entity Framework came out, it included support for database-first design, which would reverse engineer an existing database and build a model for you. You could build a model using the designer, but there was no tooling support for building a database from the model, so you had to perform that work yourself. The next version of Entity Framework, version 4, released with .NET 4 and Visual Studio 2010, added the necessary tooling support that made model-first design a viable option for using Entity Framework. Through these two releases, the database and model were the focus of early development work on a project. But if you follow domaincentered design, you probably found that Entity Framework really didn't fit into the way you create applications.

All that changed with Version 4.1 of Entity Framework, released in the early part of 2011. This version added yet another option, code-first design. Codefirst design lets you create the domain model for your application by building Plain Old CLR Objects (POCOs), with no Entity Framework code whatsoever and without using any base classes. Then, through some clever features, you can create a context class that almost magically turns the objects into fully functional entity data objects. Even more amazingly, you don't have to worry about creating the database at all. Assuming that you can live with the default conventions that you'll learn about in this chapter, Entity Framework will create the database for you automatically when you first run the application.

The way that code-first works by default will probably work for most applications early in their development cycle. But when you're ready to deploy the application to a production server, or need more flexibility in how Entity Framework creates a database, you can take advantage of data annotations on the model classes or use a fluent API to take control of the process. And even if you have an existing database that the application will use, you can still use code-first design and map the POCOs to the existing tables and fields.

The biggest benefit of code-first design is that it lets you focus on domaincentric modeling for application development, focusing on the data objects in your application rather than on the database or the Entity Data Model. In fact, your application won't even have a model, and won't have an .edmx file in the project, or any XML mapping code. Entity Framework takes care of inferring the model-including the conceptual, storage, and mapping models-at runtime. It really is a code-centric style of writing database applications.

Code-first design works so well and is implemented so nicely that we are confident that it will become the method of choice for new application development.

NOTE Code-first design is only available with Entity Framework 4.1 and later. This is an out-of-band release made available well after the release of Visual Studio 2010, .NET Framework 4, and Entity Framework 4. As a result you'll need to download and install this release separately. See the course introduction for information.

Using Code-First

There are two different ways you can use code-first for development. The first, and what we expect will turn out to be the most common way, is to write data model .NET classes in your application first, then let code-first in Entity Framework create the database for you. This is the usage scenario that you will learn about in this chapter. Using code-first this way is the easiest, most agile way to jump-start database development, and lets you evolve and refactor the application in its early stages right through to production.

Code-first can even update the database as you make changes to the model. The other usage scenario is to again create the data model classes in your application, then map those data classes to an existing database. This will provide the information Entity Framework needs to provide data access between the application and the database, without the formality of an Entity Data Model. This might sound a little like database-first design, but the difference is that you create your own POCOs rather than having Entity Framework generate them from the Entity Data Model.

As you'll learn later in the chapter, there are two ways in Entity Framework to map classes to objects in a database, no matter which usage scenario you use. One uses data annotations on the classes and properties of the data model classes, and the other uses the DbModelBuilder API to control the mapping in code.

This post is an excerpt from the online courseware for our Microsoft SQL Server 2012 Developer course written by expert Don Kiely.