Entity Framework: Design Approach
I’ve been using Entity Framework since its introduction. Entity Framework (EF) is a powerful Object-Relational Mapping (ORM) framework for .NET Framework. I’ve been debating with my teammates whether EF is better than other ORM such as OpenAccess, which I believe is true, because EF provides the necessary feature to connect our program to the database, especially if you are using Microsoft products, SQL Server. In my thinking, why bother using custom ORM to connect to SQL Server while actually Microsoft, the creator of everything (well, not, only .NET Framework and SQL Server I’m talking about here) provided the powerful tools to support your needs. In fact, Microsoft fully support the EF and provides the latest features as their development (EF and SQL Server) (should) inline each other.
Ok, I’m not going to debate about which one is better. I am going to talk about Code First approach to build your model from scratch. This is the first time I am trying using Code First approach, while previously I always use Database First or Model First approach.
Ways to Model Your Database
Entity Framework has been evolving quite rapidly. In the newest version, I noticed they are now using DbContext class instead of the old ObjectContext. And the new generated classes (if you are generating the model from existing database), will be just Plain-Old-CLR-Objects (POCOs). In previous EF, all the model classes must be derived from EntityObject. This offers more flexibility in designing your model classes.
One other notable changes I found is that the entity framework do not require the resource file definition in the connection string anymore. This will offer more flexibility in porting your model into separate DLL library and reuse it wherever you want. I am going to explore this finding later.
So to model your database, you can use three different approach: Database first, Model first, or Code first. Below is the explanation of each one of the way
This is the most classic way to design your database for your application. You start building database structure in the RDBMS, then you import the schema to ORM in your program. In this approach, you can fully utilize the power of your RDBMS. You can optimize your database directly, choose the best optimization directly, set the field length, indexing, and so on.
The thing that we need to consider when reflecting the database structure into ORM is that in database, the data stored in point of view of a table. While in ORM, which is directly in your code, it is in a point of view of Object Oriented (OO) design. Sometimes the generated ORM from database does not logically fit to the Object Oriented design. Especially if you want to model an inheritance in your model, you have to make your database is structured to store the object oriented model from the program to the database, which is sometimes quite confusing for database designer.
But when you already have database schema for your application, no matter what you have to choose Database First for your approach. Because you don’t have to work twice reimplementing the database structure in ORM format. Just let the EF generates the ORM based on the schema.
In Model First, you start designing your database from scratch. But instead of modelling the structure in RDBMS, you model it in your EF designer. You use visual diagram to model your database, after that you can let EF generates the Data Definition Language (DDL) that can be executed in the RDBMS to generate the actual database.
The good thing of using Model First is that you can build your database without the knowledge of SQL. You can model the database using OO approach and let EF find the way to store it in the database. You can implement inheritance in your model without worrying about how to represent it in database. EF will generate the best database structure to store such model.
You can also use the feature of RDBMS such as Indexing in your design. But it is not that straightforward as excecuting CREATE INDEX command in RDBMS. EF provides the way to include and execute SQL commands in the generated model. Each time you update the database based on your model, EF will execute the command to the database.
Code First is the same with Model First where you start from scratch, but instead of modelling using visual approach, you model it using code directly. Recently I found this approach is the most straightforward for person who often do coding and rarely do SQL-ing like me. Using Code First, you can directly model your ORM in Object Oriented design, and add additional method to operate your object. You can achieve this in Model First too using C#’s partial class though.
You create your ORM classes in Code First by creating a context class which derives the DbContext class. In that class, you can define the table and the class that is going to represent the table. You can also add additional configuration by defining annotation or attributes to specific field within the class. I know this is sounds so greek, but later we will talk on developing ORM using EF’s Code First approach. 🙂