Ado. NET: Use the Entity Framework to flexibly model data

This article describes the following:

The rationale behind the Entity Framework

Entity Data Model

query, mapping and N-tier development

This article uses the following techniques:

Ado.net, LINQ, Entity Framework

The framework concept was first introduced in 2006 as a ado.net Vnext, and is now ready to be launched in the upcoming Visual studio®2008 SP1. After many years of failed attempts at similar products, Microsoft released some of the following two technologies that are appropriate for object relational mapping (ORM) space with Visual Studio 2008: LINQ to SQL and Ado.net Entity Framework. As the market begins to adopt these technologies, developers want to understand our current situation and the future direction of Microsoft. They also want to understand the rationale behind these technology developments, the fact that the Entity Framework differs from other ORM technologies on the market, and Microsoft's investment trends in these technologies.

At the beginning of Visual Studio 2008, there was a lot of articles about LINQ to SQL, and articles about which technology should be used. Here I will focus on the Entity Framework and explore in depth how you should choose and why you should do so in the development process.

The Microsoft® Entity Data Model (EDM) is based on Dr Peter Chen's Entity Relationship (ER) model, which is actually the driving force behind the ado.net Entity Framework. The EDM is also the most obvious feature of distinguishing between the Entity Framework and other ORM technologies on the market. The EDM builds on the ER model, raising the abstraction level of the model to a level higher than the logical model, while still preserving the concepts of entities and relationships.

Why do you need to build another data model?

So why do we need to build another model? As corporate data processing increases, it becomes difficult to streamline data relationships and develop applications based on these data. The database architecture is designed to take into account storage issues such as data integrity, performance, and management, which are sometimes not easily understood. These architectures also frequently conflict with the structure of the application, making development and maintenance work more complex.

We often encounter custom solutions that are split between data structures and the applications that are built. Unfortunately, for each application, the number of custom solutions, the various methods, and the steps required to model the data are all different, causing problems to occur continuously. The entire industry wants a way to define and develop a domain model at the application level so that it can be clearly separated from the storage of the logical model. Therefore, the Entity Framework is introduced.

The EDM (see the example described in Figure 1) allows you to define a domain model in such a way that organizations view and use data, rather than how the data is stored. The main goal of developing an EDM is to become a core data model for developer and server technology suites within Microsoft.

Figure 1 Sample Entity Data Model for a blog database