I have just closed the DC - Provide support for dynamic members in domain components ticket with two possible solutions (there were some specifics with regard to the late generation of real XPO classes for DC interfaces) and wanted to use this chance to draw your attention to some advanced stuff you may need one day - customizing your data model metadata at runtime via the underlying types info subsystem (ooohhh!)
In short, you may need customizations at this low level when you want to dynamically adjust your ORM data model mappings to the database, add or remove custom members for your data model at runtime (e.g., based on the info stored in the database, XML settings file or any other source) when implementing an app tailored to a specific client/user access rights, etc.
Leaving customizations aside (which is quite rare, to be honest), accessing information about the types (their metadata) registered within the XAF application is really common. For instance:
Our documentation describes this in several articles here:
eXpressApp Framework > Concepts > Business Model Design > Types Info Subsystem
I have also prepared a small schema to better explain the role this type of info subsystem plays:
As you can see from the schema, this 'types info subsystem' serves as a source for Application Model and thus UI generation. That said, in certain scenarios, you may want to access certain info at a higher level instead of accessing the types info subsystem directly.
If you are anxious to see more advanced XAF stuff today, consider reviewing my previous post at
How to customize the underlying database provider options and data access behavior in XAF.
See Also:
eXpressApp Framework > Concepts > Business Model Design > Data Types Supported by built-in Editors
In short, you may need customizations at this low level when you want to dynamically adjust your ORM data model mappings to the database, add or remove custom members for your data model at runtime (e.g., based on the info stored in the database, XML settings file or any other source) when implementing an app tailored to a specific client/user access rights, etc.
Leaving customizations aside (which is quite rare, to be honest), accessing information about the types (their metadata) registered within the XAF application is really common. For instance:
- If you want to check what business class this View is for - check the View.ObjectTypeInfo property.
- If you want to check the member a PropertyEditor corresponds to - check its PropertyEditor.MemberInfo property.
- Need to know whether a business class has a certain property? Use the ITypesInfo.FindMember or ITypeInfo.Members APIs.
- Want to know which code attributes are applied to a class or property? Call the IBaseInfo.FindAttributes method (check examples here).
- Want to get/set a class property known only at runtime? Use the IMemberInfo.Get/SetValue methods (see an example in the end of this article - it's like .net reflection, but faster).
Our documentation describes this in several articles here:
eXpressApp Framework > Concepts > Business Model Design > Types Info Subsystem
I have also prepared a small schema to better explain the role this type of info subsystem plays:
As you can see from the schema, this 'types info subsystem' serves as a source for Application Model and thus UI generation. That said, in certain scenarios, you may want to access certain info at a higher level instead of accessing the types info subsystem directly.
If you are anxious to see more advanced XAF stuff today, consider reviewing my previous post at
How to customize the underlying database provider options and data access behavior in XAF.
See Also:
eXpressApp Framework > Concepts > Business Model Design > Data Types Supported by built-in Editors