When I first came into contact with Visual Studio DSL, I was confused by its basic theoretical concepts for a long time. My suggestion is that it would be best if I could quickly understand these concepts. if you cannot understand these basic concepts in a short period of time, there is no need to go deep into each concept for your own headache. It is better to go deeper in future practices, understand and deepen these concepts.
To develop a DSL, you need to create several different components: domain model, graphical symbols, toolbox, resource manager and attribute window, verification, serialization and deployment, open dsldefinition in the mongoagesm project we created in the previous section. DSL file, you can see that there are two left and right sections (two swimming paths) in the central document area ).
1. the metadata model (domain model) is on the left, that is, the relationship between domain classes and domains.
2. The right side is the graphic match, that is, the graphic element (dimo-elements ).
In fact, we are using DSL itself to create DSL. These descriptions are also using DSL.
In addition, Domain Models and graphical symbols are connected through connectors, and domain classes can be connected through relationships.
Domain Model (Domain Model)
The core of each DSL is a domain model, which defines various concepts represented by languages, their attributes, and their relationships. In model-driven development, our models must be abstracted and described using DSL syntax. This is described using a domain model. As long as we have a domain model, toolbox, graphic Display is created based on the domain model.
The domain model has two concepts:
1. Root Domain class)
Any DSL has only one root domain class, which corresponds to your graph. The graph here is the concept of the whole graph. From the project in the previous section, we can see that the root domain class (examplemodel) and its corresponding graph (exampleshape) are automatically created by default ).
2. Domain class)
Unlike the root domain class, exampleelement is a real model. And it has Attribute , Name is name, type is string.
Domain relationships)
1. Embedded relationship (embedding relationship)
The embedding relationship indicates that a model can be embedded in another model. In our DSL, we can find the embedding relationship examplemodelhaselements and associate examplemodel with exampleelement (SEE ).
The attribute name at the end of examplemodel is elements. This set attribute contains all exampleelements with a weight of 0. *, indicating that it can contain zero or multiple exampleelements, A domain role is the role it plays in this relationship. You can click the domain role (this line) in the attribute on the right, the role name is often the opposite of the source attribute name on the other end. .
The attribute name at the end of exampleelement is examplemodel, which indicates the type of examplemodel that it belongs to. The weight is 1 .. 1, indicating that it can and can only belong to one examplemodel.
To put it simply, this embedding relation indicates that multiple exampleelements can be put in our examplemodel model in all the last running DSL. For each exampleelement, it can only belong to one examplemodel.
2. Reference relationship)
In our DSL, we can see that the reference relationship exempleelementreferencestargets links two exampleelements, indicating that the exempleelementreferencestarget relationship can be established between two exampleelements. The reference relationship is generally graphically represented, therefore, when designing a model, we drag a line to link the two models. Like the embedded relationship, the reference relationship can also be set to multiple, indicating whether multiple models are allowed to establish reference relationships at the same time. In our example, the source and target are the same, and the weight is 0 .. *, indicating that an exampleelement can establish a reference relationship with multiple other exempleelements.
Note that this does not mean that multiple duplicate references can be established between two exampleelements, but between different exampleelements. To allow repeated links, you must set allows duplicates to true in the Link Attributes. in addition, DSL generates a separate class for each domain relationship, and each link established in the model is an instance of this class. We can control the generated Code You can set the generatesdoublederived attribute to true. Each link generates two classes. The parent class examplemodelhaselementsbase contains all the implementations. The subclass examplemodelhaselements is a partial class, therefore, you can reload the methods of the parent class to implement your own logic. In addition, we can also use this mechanism to implement a custom interface in the generated code. Note, You can also set it on the domain class. .
Here I think it is necessary to differentiate several concepts:
Domain class-Domain Model :
The domain model contains the domain class and the domain relationship. The domain class represents different types in the domain, and the domain relationship represents the relationship information in the two domain classes.
(1) domain model -- all
(2) domain library
(3) domain person
(4) domain relationship
(5) repeated Number * (indicating that a library can have multiple persons in a domain model ).
(6) count 1 (represents a person and can only exist in one library ).
(7) Source role
(8) Target role
Domain attributes --- attributes
In a domain model, a domain class can have a bunch of domain attributes, which are linked to the domain and describe the metadata. However, for each domain class, we can also list some attributes, such as descriptions and names, in the property editor of the DSL designer. Note that the name attribute here is different from the name attribute of this domain class. The attribute column lists the attributes of the domain class, that is, the name of the domain class.
The DSL diagram lists its domain attributes, and each domain attribute is actually an element, so it also has some attributes, the name here is actually the name shown in the figure.
Now, we are here to digest it.
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.