[Programming Entity Framework] Chapter 2nd exploring the Entity Data Model (EDM) (ii)

ArticleDirectory

• Entitycontainer
• Entityset
• Entitytype
• Association
• Navigation Properties
• Returns the navigation attribute of the set.

Programming Entity FrameworkVersion 2Translation Index Metadata supported by the Model

So far, you have only seen the concept of the model in the designer, and its edmx has a more important part: storage model and ing.

Note: in fact, the edmx file contains four parts, but the fourth part contains the designer commands for object locating. My discussion here will ignore that part.

The additional parts of these metabases allow you to use EF APIs to convert conceptual models and real data storage. The storage model represents the architecture of the database objects you select. ing describes how to place the entities and attributes of the conceptual model into the tables and columns described in the storage model. (See figure 2-7 ).

When real data storage is available, why do we still need to use the storage layer that represents data storage? There are many reasons for using this model. The most important reason is that it provides loose coupling to the database. Not every object in the database needs to appear in the model. You will learn this in Chapter 6th. It is possible to customize the storage layer to fit the model.

Although the entity model is included in a single file during design, after the project is compiled, it creates a separate file for these parts, a total of three separated files. The concept layer is saved to a file with the extension. CSDL, which indicates the definition language of the conceptual mode. The storage layer is saved to a file with the extension. SSDL (indicating the storage mode definition language), and The ing layer is saved to a file with the extension. MSL (ing standard language. These files are used at runtime, which is why they are included in the module named edmx: runtime in the model.

Note: by default, you will never see these Implementation files because they are embedded in the assembly of the project during project compilation. This is advantageous in many scenarios, even though it is possible to modify the artiface processing attribute of the model to read "Copy to output directory.

other nicknames in mode you will see a variety of descriptions on the three parts of the model in documents, articles, training, and even the book. The following lists their various nicknames: Definition Language (CSDL): Concept layer concept mode Conceptual Model C-side storage mode Definition Language (SSDL ): storage layer storage mode Storage Model store metadata metadata storage mode S-side msing Specification Language (MSL ): ing layer ing specification C-S ing (refer to concepts to storage)

each part is controlled by its own XML schema definition file that exists in the. NET Framework file. A schema file defines the structure of CSDL, MSL, and SSDL. Vs smart sensing uses these files to help you directly operate XML files, identify errors, and present option values. Compilation errors are also displayed if they are inconsistent with their pattern rules.

Architecture If you are curious, you can take a look at the framework file that defines rules for CSDL, SSDL, and MSL in the model. The architecture file in vs2010 is located in c: \ Program Files \ Microsoft Visual Studio 10.0 \ XML \ schemas. If you are running in a 64-bit operating system, use program files (86) instead. The three files look like the following: System. Data. Resources. csdlschema_2.xsd System. Data. Resources. csmsl_2.xsd System. Data. Resources. ssdlschema_2.xsd If you open them in Vs, you will see formatted XML files that are easy to manipulate.

 

View the model in the Model Browser

The Object Data Model Designer also provides another view of metadata in the Model Browser. You can enter the Model Browser in the context menu of the model design interface.

Figure 2-8 shows the Model Browser With some expansion items. The Model Browser gives you an overview of CSDL and SSDL items. Here you can enter the Properties window for different entities and attributes. You can also right-click and choose to navigate to a specific object or attribute in the designer display. As models become more complex, model browsers are a convenient way to view organized metadata views.

View Native XML of the Model

Now it's time to take a look at EDM. Only a part of the model is visible in the designer, which means you can learn more by viewing its original format. You can see the two views in the locations where the designer model has copies.

By default, files are opened in the designer; therefore, you need to use another method to open the original file. In the solution browser, right-click the model1.edmx file. In the Open menu, select open with tools, select XML editor, and click OK.

Vs cannot display XML in the designer and XML at the same time, so you will see a message prompt asking whether to disable the designer view of the model. Click Yes.

Note: For friends with XML syndrome, it may seem a little timid at first. Don't be afraid, just keep following. We will not go into depth, but if you are very interested, you will find more details about native metadata in appendix C.

In subsequent chapters of this book, you will deal with XML files directly, and some designers do not support model customization. In addition, you will write something that directly interacts with the native model.Code. When performing these tasks, you will feel the benefits of dealing with XML files in the following pages and appendix C.

The edmx file consists of two main modules: runtime information and designer information. The runtime module consists of three other modules: storage module, concept module, and ing. The Designer module specifies the location where different model elements should be placed in the designer's visual graphics.

Collapse all main modules of the model. You can right-click the XML file, select the outline, and collapse all to the outline. Now you will see the main code, edmx: edmx. You can expand it to view the same view as 2-9.

Now you can see the main modules of the model. The design element tells the designer how to place entity metadata. You can freely browse it later. The main modules of the model are conceptualmodels, storagemodels, and mappings.

 

CSDL: Concept Mode

Let's begin to savor the concept of CSDL and EDM. In the XML file, click the + sign to expand the conceptualmodels module until you see the schema and entitycontainer. See figure 2-10.

Note: Sometimes the formatting of XML is affected, and a part of XML may lose its carriage return, which makes it difficult to format very long lines of code. To fix this problem, select the row and select edit-advanced-format in the vs menu. This will make XML formatting smoother.

Here you see entitycontainer, entitysets, and various entitytypes. They are defined in the metadata and contain different entitysets in the previous designer.

Now let's take a look at this structured XML to learn more about the different elements in the object data model.

Entitycontainer

The mode contains the entitycontainer called sampleentities (by default. Like a command space, entitycontainer uses the Database Name and adds the word entities to it by default. When you open a model in the designer, you can view and modify the name in the model Properties window.

Entitycontainer is the container of entitysets and associationssets. In Figure 2-5, you can identify the entityset of contacts from the attribute window. Associationsets are associations between entities. We will return to associationsets after discussing the association elements.

As shown in 2-11, entitycontainer is an important entry for querying models. It exposes entitysets, which are the entitysets on which you write queries. Entitysets in turn allow you to access their entities.

Entitycontainer has an attribute: annotation: lazyloadingenabled = "true ". Annotation only exists in the edmx file. It is an instruction for generating code based on the model and has nothing to do with the model itself. This setting can also be seen in the model Properties window.

Entityset

Entityset is an entity container. Its two attributes are name and entitytype. Entitytype uses its strong type name to define the types of objects contained in the set. The strong object type name is included in the model namespace. The following code snippet:

<Entityset name = addresses"

Entitytype = "samplemodel. Address"/>

<Entityset name = "contacts"

Entitytype = "samplemodel. Contact"/>

When you query a model, you can use entityset to access a single object. In the next chapter, you will see what code translation you use to translate "Search for certain entities in addresses entityset ". The model command returns the address object type for your query.

Note: As you will learn in this book, the Entity Data model allows you to inherit data types. Therefore, your model may have contact entities and customer entities. Customer is a type of contact. In this case, the contacts entityset serves as the package for the contact and customer entities.

Entitytype

The object type is the data type in the model. You can see the contact object type and address object type.

In XML mode, expand the address object type. You will see the example 2-1, and take a closer look at it. It includes primary key elements and a list of attribute elements.

Example 2-1. The address entity's XML

<Entitytype name = "Address">

<Key>

<Propertyref name = "addressid"/>

</Key>

<Property name = "addressid" type = "int32" nullable = "false"

Annotation: storegeneratedpattern = "Identity"/>

<Property name = "street1" type = "string" maxlength = "50"

Unicode = "true" fixedlength = "true"/>

<Property name = "street2" type = "string" maxlength = "50"

Unicode = "true" fixedlength = "true"/>

<Property name = "city" type = "string" maxlength = "50"

Unicode = "true" fixedlength = "true"/>

<Property name = "stateprovince" type = "string" maxlength = "50"

Unicode = "true" fixedlength = "true"/>

<Property name = "countryregion" type = "string" maxlength = "50"

Unicode = "true" fixedlength = "true"/>

<Property name = "postalcode" type = "string" maxlength = "20"

Unicode = "true" fixedlength = "true"/>

<Property name = "addresstype" type = "string" nullable = "false"

Maxlength = "10" Unicode = "true" fixedlength = "true"/>

<Property name = "contactid" type = "int32" nullable = "false"/>

<Property name = "modifieddate" type = "datetime" nullable = "false"/>

<Navigationproperty name = "Contact"

Relationship = "samplemodel. fk_address_contact"

Fromrole = "Address" torole = "Contact"/>

</Entitytype>

Primary Key Element

The primary key element defines the attributes of the primary key of the model. In the designer and runtime, you will see it as entitykey. The primary key of an object plays an important role in the lifecycle of an object. This makes your applicationProgramKeep track of entities, update and refresh databases, and so on. You will learn this in Chapter 10th. In the designer, you can specify a primary key in the attributes of an object.

The primary key of the address object only uses a single attribute, addressid. A primary key can use a combination of multiple attributes. They are called federated object primary keys, which are similar to the federated primary keys in databases. You will learn more about the federated primary key in Chapter 10th.

Attribute Element

Attribute elements not only have names, but also have other aspects defined by their data types, which further describe attribute elements.

The data type that defines these attributes is called a simple type. They are basic types in the EF object model, similar to the data elements in the. NET Framework. However, the basic type of EF is only used to define the attributes of an object. They do not have their own attributes. They are really simple.

From 2 to 12, you can view and edit most of the information in the Properties window.

You can see that some of the properties displayed in the Properties window are not displayed in XML.

Note: you cannot open the XML and designer at the same time. To return to the designer, close the XML view of the model and double-click the edmx file.

Attributes with default values are not displayed in XML files. This is a situation of the address. street1 attribute, including concurrencymodel, default value, Getter, and setter. The entitykey attribute is not an aspect of street1, but it is used to create the entitykey element, which we described earlier. If you view the addressid attributes, you will see that its entitykey attribute value is true.

Note: The getter and setter attributes define the accessibility of each attribute of the class generated from the model object. By default, all attributes are public, allowing anyone to read and write data. Modifying the values of getter and setter affects the declaration of attributes. Chapter 2 discusses concurrency in depth, where you will learn about the concurrencymodel attribute.

Navigation Properties

The link between the navigation attribute of an object and the link between the object is closely linked, as you can see in Figure 2-3 above. We will discuss the topic of navigation attributes in depth later on the association.

Association

An association defines the relationship between object types. However, the association is not fully defined. It defines endpoints (such as entities involved in links) and their duplicates.

In the sample model, there is only one association. It is between the contact and address entity types, which tells us that there is a relationship between them. When the wizard creates a model for the first time, the associated name uses the database-defined relationship. Like any other element in the model, if you prefer a more readable name or you have command rules to follow, you can modify the name of the association.

Let's first look at the associated attributes in the design view. If you keep following the operation, close the XML, open the model in the designer, and click join. Figure 2-13 shows the attribute window for association between contact and address.

 

Link to list the two ends. Endpoint 1 is the contact entity type. It is assigned a role called contact, which acts as the name of endpoint 1, so that any element in the model can point to it. In addition, the attribute of endpoint 1 tells us more information about this end in the association. The number of duplicates indicates that only one contact appears in the relationship between the contact and address. The navigation property shows the address property in the contact type, which takes us to the other end of the association. The ondelete attribute. The optional values include cascade and none, indicating that when the contact object is deleted, any other related entities in the contact object will also be deleted.

Endpoint 2 is the address entity type. In this relationship, multiple addresses exist. After reading the association, you can see that there is a one-to-many relationship between the contact and address. The contact may have a home address, work address, or even other addresses. However, an address can only be associated with a single contact. In the real world, an address may have relationships with multiple people, such as family members, roommates, or employees in the same company. It will involve many-to-many connections, which we will discuss in Chapter 8th.

For the entity, the association defines the name of the associationset containing the association. By default, it matches the associated name. You can also use the plural name, but this method does not have the same key as the plural entityset name because it does not need to interact with associationsets in the code.

Note: learn more about associationset in appendix C.

Finally, add annotations to the referential constraint attribute. In a model that contains foreign keys in an object, the reference constraint of the contactid attribute of address shown in example 2-14 is critical. It defines the dependency between related entities.

Each address object must point to a contact. When you store data to the database, the reference constraints will check these.

Note: To be backward compatible with version 1 models, you can still define constraints using association ing when there is a relationship between two primary keys.

The default method is to include foreign key attributes when creating an object data model. You can create a model that does not contain foreign keys as in a version. In this case, the reference constraints will not be used, and the dependency between the contact and address is defined by the association ing. In Chapter 2, you will learn more about this alternative use. In this model, associations are called independent associations, while those using foreign keys in the model are called foreign key associations.

We will discuss more details about Association later in this chapter. In chapter 19th, we may even be more careful. It focuses on relationship and association.

Navigation Properties

Finally, let's take a look at the navigation attributes in the address and contact object types. So far, I have explained Association, and navigation attributes should be easier to understand.

Although it is easy for an object to have more than one navigation attribute, there is only one object type in this particular model. Figure 2-15 shows the Properties window of the contact navigation attribute address object.

When you work with the address in the Code, the contact navigation attribute only appears as another attribute. Although other attributes are called scalar attributes, they all mean that they are values. Navigation attributes describe how to navigate to related entities.

The most important attribute of navigation is Association. It describes the navigation attributes associated with the model that contain information about how to navigate to the associated object (here it is the contact. Addresses object.

As I have explained before, the association defines the relationship between the address and the contact object type. Fromrole and torole tell this when EF is concerned. It needs to navigate from the endpoint named address to the endpoint named contact. This allows you to navigate from the address entity to its associated Contact entity in the code.

As for the entity and the master, the designer shows some attributes used for code generation: getter, setter, and documentation. In addition, the multiplicity is connected to the same end in the association. You can modify the attributes in the navigation attributes or associated attributes. The weight of a contact is 1, indicating that you will get a contact instance when you navigate to address. Contact. The returned navigation attribute of a single object is called a navigation reference. The returned type is the read-only attribute in the designer Properties window, so that you can better understand the navigation.

When you focus on the same navigation attribute in the XML file, you will not see the last two attributes, because the getter, setter, and documentation attributes both use the default values, they are not listed like the following code snippets:

<Navigationproperty name = "Contact"

Relationship = "smaplemodel. fk_address_contact"

Fromrole = "Address"

Torole = contact "/>

Returns the navigation attribute of the set.

The contact attribute of the address object returns a single instance of the contact. What is the addresses attribute of the contact object? Figure 2-16 shows the addresses attribute.

When you navigate from contact to addresses, the addresses endpoints defined in the relationship fk_address_contact have multiple duplicates. Therefore, EF expects to be a set in the addresses attribute. In the designer, the return attribute of addresses is a set of address types.

This type of navigation property is called a navigation set.

In the code, the contact. Addresses attribute returns the set of address entities, even if there is only one address in this set. If a person does not have addresses, the set is empty.

The Set exposed in the addresses navigation attribute is not from the set in the system. Collections namespace, but entitycollection. It is the unique class in EF. Therefore, although it is easier to say "A addresses set", you can use the "entitycollection" function. collections. when icollection types work together, pay more attention that they are not interchangeable.

Remember that in this simple model, the concept layer is not customized. It is a portrayal of the database model and the best starting point for learning EDM. After this book, you will learn about custom models and start to understand the real power of EDM.