Visual Studio DSL entry 5-understand the generated domain classes and domain relationships

In the previous section, we introduced some basic concepts of the vs.net DSL domain model. In this section, we will go back to the lanuagesm project we generated and look at the generated domain classes and domain relationships, introduce the store during DSL running, and then introduce some key points worth attention. Make the final preparations for designing our own DSL for our next section.
1. First, find the domainclasses. CS generated by the template domainclasses. TT in the DSL project. Let's take a look at it. It consists of two classes:

In fact, it corresponds to the root domain class examplemodel and domain class exampleelement in our domain model. Let's take a closer look at the specific structure of the exampleelement class. We can find that:
1 ). the field is of the guid type, which makes it easier to directly reference attributes in the relational class. In the future, we will also find that the guid field variable of the attribute is often used to represent the attribute during verification.
2 ). we can see the property generated by the link we saw in the previous section. The embedding relationship between exampleelement and examplemodel generates the examplemodel attribute of the examplemodel type. the reference relationship between exampleelement and itself. because the number of duplicates is *, The linkedelementcollection <exampleelement> attribute of the strong set type is generated.
3). The name in the attribute represents the domain attribute name of the domain class.

 

2. Let's take a look at the domain relationship, find the class file domainrelationships. CS generated by domainrelationships. tt, and view the class diagram. The attributes in the class diagram are links or composite links:

1) you can see that the class corresponding to the domain relationship is associated with the domain class through the field corresponding to the guid.
2) through the class diagram above, we can see the relationship between the attributes of the domain relationship class and the domain class, which respectively store the attributes of the source and target corresponding to the relationship.
3) We can find some static methods, such as in the examplemodelhaselements class:
Getelements (examplemodel) --- obtains all exampleelements corresponding to an examplemodel in a link.
Getexamplemodel (exampleelement) -- obtains the examplemodel corresponding to an exampleelement in a link.
You can also use getlink, getlinks, and getlinkstoelements to obtain the relationship between the specified elements.

3. It is necessary to have some knowledge about the running mechanism of DSL here, so we must introduce the store here.
1) During DSL operation, model elements are stored in the store in the memory. sotre also provides a series of operations: creation, operation, and deletion of Model Elements and relationships, redo/undo, rules, events, and so on are very important. In DSL development, store operations are often involved.
2) When a model file is opened, a store is automatically rebuilt and all models and links in the model file are loaded. This process will be described later.
3) each domain class inherits modelelement, and each domain relation inherits from elementlink (elementlink actually inherits from modelelement ). each model loaded in the store is actually an instance of modelement, and each domain relationship is an instance of elementlink. You can use store or even operate on their attributes to listen for events such as creation and deletion.

4. There are some detailed issues that should be paid attention to here:
1 ). to distinguish whether two domain classes are embedded or referenced, consider the presentation of these domain classes in the Model Browser. If they are embedded in the Model Browser (Model Explorer), you can use the embedding relationship, otherwise, the link is referenced.
2). Although you can choose the weight of a link, there are some restrictions in some cases, such as in an embedded relationship:
The weight of the target role of the embedded link can be one or zeroone, because a modelelement can only be embedded once.
If a modelelement is a target role in multiple embedded relationships, the weight of the target role must be zeroone, because it can only assume the target role in a relationship at the same time.
In a complete domain model, each domain class (except the root domain class) must be the object of an embedded relationship. Otherwise, a complete model tree cannot be formed and serialization cannot be processed.
Of course, you may be confused about these rules. You can ignore these rules and design them in your own way. When saving or verifying (right-click Validate all, you will be prompted in the following error window.
3) each domain class should have name domain property. you can drag the named domain class from the toolbar to create a domain class to automatically bring out the domain attribute. You can also manually add the domain attribute and specify that the is element name of the domain attribute is true, the value of this attribute is used for serialization.

Author: lone knight (like a year of water)
Source: http://lonely7345.cnblogs.com/
The copyright of this article is shared by the author and the blog. You are welcome to repost this article, but you must keep this statement without the author's consent andArticleThe original text connection is clearly displayed on the page. Otherwise, the legal liability is retained.