-
Notifications
You must be signed in to change notification settings - Fork 0
Identity
Each entity modeled in the CodeModeler model generates two classes: a class named as the entity, and a second one named [EntityName]Collection in order to handle sets of the first one. Identity features are implemented on the first class, mentioned hereafter as the entity class.
Each generated entity class implements the .NET Framework interface System.IEquatable<T>, T being the type of the generated class. Consequently, for this model:
Each entity class (in this case the class would be Customer) will contain the two following methods:
public override bool Equals(object obj)
{
MyNamespace.Customer customer = null;
customer = obj as MyNamespace.Customer;
return this.Equals(customer);
}
public virtual bool Equals(MyNamespace.Customer customer)
{
if ((customer == null))
{
return false;
}
if ((this.Id == -1))
{
return base.Equals(customer);
}
return (this.Id.Equals(customer.Id) == true);
}
The code above might change depending on the key type, or on other parameters that might be specified in the model.
Whatever the key type might be, entity classes always have an EntityKey property. This property returns a string representing the key of the current entity. For instance, the model shown previously would generate the following code for the Customer class:
public virtual string EntityKey
{
get
{
return this.Id.ToString();
}
set
{
this.Id = ((int)(ConvertUtilities.ChangeType(value, typeof(int), -1)));
}
}
This property gets handy when handling composite key entities. In those cases, keys are composed of several objects that might be of different types. The complete key representation will be held in the EntityKey property. For instance:
In the model above, we modified the previous Customer entity to contain a composite key (Id + TenandId). Therefore, the generated code for the EntityKey property will change to this:
public virtual string EntityKey
{
get
{
object[] keys = new object[] {
this.Id,
this.TenantId};
string v = CodeModelerPersistence.BuildEntityKey(keys);
return v;
}
set
{
System.Type[] types = new System.Type[] {
typeof(int),
typeof(int)};
object[] defaultValues = new object[] {
-1,
CodeModelerPersistence.DefaultInt32Value};
object[] v1 = CodeModelerPersistence.ParseEntityKey(value, types, defaultValues);
this.Id = ((int)(v1[0]));
this.TenantId = ((int)(v1[1]));
}
}
It's good to know that when it comes to composite key entities, it's the EntityKey property that will be commonly used for identity purposes; rather than the direct property as it could be done for non-composite entities. This way composite keys are automatically handled, without configuring, changing nor customizing anything special.
The EntityKey property of composite key entities is built by concatenating the keys using the entity key separator (which is a pipe ('|') by default). However, it's possible to change that separator by specifying the EntityKeySeparator application setting in your application configuration file (commonly called App.config or Web.config). Furthermore, developers can find a set of very useful public methods and properties in the CodeModeler.Runtime, such as the CodeModelerPersistence.BuildEntityKey and the CodeModelerPersistence.ParseEntityKey used in the code sample above.
The GetHashCode method is a method available on the System.Object class. The GetHashCode method is suitable for use in hashing algorithms and data structures such as a hash table.
In .NET development it is best practice that value types or objects used in hash tables override the GetHashCode method; hence CodeModeler generated classes do so. For more information on the GetHashCode method and its purpose please check .NET’s official documentation.
public override int GetHashCode()
{
return this._id;
}
The code above might change depending on the key type. For instance, an entity identified by a composite key will use the EntityKey.GetHashCode() value.
The EntityDisplayName is for UI and debugging purposes. By default, the EntityDisplayName value of an entity class corresponds to the first property of the string type. If ever the collectionKey attribute is used on one of the string typed properties, the EntityDisplayName will correspond to that property. Moreover, you can explicitly set the EntityDisplayName property by setting the entityDisplay XML attribute. This way, the property defining this attribute, will be used by the EntityDisplayName property.
For instance, the following model:
Generates a different EntityDisplayName per entity:
-
The Customer entity uses the first string property,
-
The Order entity uses the collection key property,
-
The Product entity specifies explicitly the property to use.
Here are the three different generated source codes for the EntityDisplayName property:
public virtual string EntityDisplayName
{
get
{
return this.Name;
}
}
string CodeModeler.Runtime.ICodeModelerEntity.EntityDisplayName
{
get
{
string v = this.EntityDisplayName;
return v;
}
}
public virtual string EntityDisplayName
{
get
{
return this.Code;
}
}
string CodeModeler.Runtime.ICodeModelerEntity.EntityDisplayName
{
get
{
string v = this.EntityDisplayName;
return v;
}
}
public virtual string EntityDisplayName
{
get
{
return this.Label;
}
}
string CodeModeler.Runtime.ICodeModelerEntity.EntityDisplayName
{
get
{
string v = this.EntityDisplayName;
return v;
}
}
- Introduction
- Architect Guide
- Concepts
- Using Visual Studio
- Overview
- Creating a CodeModeler Project
- Visual Environment
- Project Hierarchy
- Design Surface
- Customizing Design Surfaces
- Ribbon Bar
- Property Grid
- Member Format Expressions
- Model Grid
- Method Editor
- View Editor
- Instance Editor and Grid
- Resources Editor
- Inferred Model Viewer
- Building
- Project Physical Layout
- Source Control Support
- Generating
- Aspect Oriented Design (AOD)
- Developer Guide
- The Business Object Model (BOM)
- CodeModeler Query Language (CMQL)
- Starting Guide - Tutorial
- Upgrade From CFE