Entities
The first stage when developing an application using SoftFluent CodeModeler is to define your business logic in your model. Therefore, one needs to model his business concepts so they can be interpreted by CodeModeler, and this is done thanks to entities: entities represent business concepts. For instance, an online shop handles concepts like customers, orders, and products; those concepts can be modeled by three equivalent entities: Customer, Order, and Product.
Once entities are declared, relationships can be set between one another. To pursue our example, a Customer can have Orders, and each Order can have one Customer and several Products. CodeModeler handles different types of relationships such as associations (as in our Customer / Order / Product example), compositions, or inheritance. Unlike inheritance, association and composition relationships are set through Properties which is another CodeModeler concept that will be discussed later, in this documentation. On the other hand, inheritance between business concepts are handled by the Entity concept. All those relationships and concepts are developed with more details in the sub-sections of this section.
From the modeled entities, CodeModeler will create a business object model which can then be produced. One can define what gets produced by defining the desired producers. Producers will produce from the designed object model, optimized code for a specific technology. By default, CodeModeler is shipped with a set of standard producers such as a Microsoft SQL Server Producer, a Business Object Model Producer. Consequently, depending on the defined producers, the produced output will differ.
This section and its sub-sections present available features provided by the CodeModeler Entity concept and how developers and architects can leverage from them to design model driven applications.
This quick example demonstrates how to model two entities related to one another: An Employee and an Address, with the Employee entity having only one Address, both entities being declared in the same MyModel namespace:
By default, CodeModeler generates two C# classes in the Business Object Model (BOM) from an entity: an entity class named after the entity name, and a class representing a set of the defined entity named [EntityName]Collection.
The generated collection class is designed to facilitate manipulation of defined entity sets and this is done by implementing specific .NET interfaces and attributes. For instance, an entity set class implements by default INotifyCollectionChanged, IBindingList, etc. Furthermore, those classes are all serializable by default and can serve as data objects.
By default, the entity class will implement a combination of list and collection interfaces so that developers can manipulate sets of the entity as a list or as collection. However, it's possible to the architect to define how a particular entity set should be manipulated by defining the “Collection Type” attribute on the entity and setting its value to the desired output:
Available values are:
-
List: the output entity set is a list,
-
Collection: the output entity set is a dictionary,
-
ListCollection: the output entity set is a combination of a list and of a dictionary. This is the default value.
Moreover, the fact that an entity is of the List collection type allows the developer to sort the set thanks to the comparer property (which is the entity key by default).
Likewise, the fact that an entity is of the Collection collection type allows the developer to use the set class as a dictionary where the collection key (which is the entity key by default) can be used as the dictionary key.
The comparer property can be defined by setting the “Is Comparer” attribute (“Advanced Properties” tab) of a property to True. Otherwise, the entity key will be used as the comparer property:
The collection key property can be defined by setting the “Is Collection Key” attribute of a property to True. Otherwise the entity key will be used as the collection key:
Namespaces defined in CodeModeler meta model result as standard .NET namespaces in the Business Object Model (BOM). They can also result as Schemas in relational database such as SQL Server. They are also simply a natural way of grouping and organizing entities.
Namespace syntax is exactly the same as .NET namespace syntax, they are delimited by using the ‘.’ operator.
A CodeModeler project always defines a default namespace which is the first piece of information required to be able to create a project:
Each entity and enumeration can be given a “Schema”. Schema are optional and are usually related with the persistence side of the CodeModeler inference engine. You can define a default schema at project level and/or specify one at concept level (mostly entity).
Some producers don’t use this notion (for example the BOM producer), but some do. For example, the SQL Server producer uses each entity’s schema to create the associated table in a SQL Server Schema. For example, let’s define the model shown in the following image:
By default, all entities will have a schema unset, so the resulting tables created by the SQL server producer will be defined in the standard “dbo” schema:
You can use the namespace as the schema for the whole project if you change the “Default Scheme Name” attribute (“Advanced Properties” tab) at project level to be {3}:
In this case, the resulting tables created by the SQL server producer will be defined in a schema corresponding to their namespace:
Note: If two entities have the same name, you will have to give them different schemas so their corresponding tables can be created in the database, or you will have to define manually their persistence names.
Each entity and enumeration can be given a category. A Category is just a name, or a path composed of names separated by dots. The list of categories in a project is defined implicitly by categories given to its types. For example, in the following image, we set the Vehicle category to the Inventory entity:
Note: Beyond namespaces, and schemas, categories are another way of grouping concepts, programmatically or visually in Visual Studio.