There is no official support for this scenario, however this does not mean that XAF is not designed with the highest standards. It means that we do not have docs and tests that can cover all possible combinations. However XAF is a flexible beast and we will go for supporting this case as short as possible.
Domain Components
With XAF it is possible to design business objects from interfaces! Given those interface DC with smart algorithms create concrete persistent class at runtime. It is possible to explore the DC dynamic assembly by overriding the in solution’s WinApplication descendant as shown:
public partial class DynamicMemberAliases2WindowsFormsApplication : WinApplication {
protected override string GetDcAssemblyFilePath() {
return Path.Combine(AppDomain.CurrentDomain.SetupInformation.ApplicationBase, DcAssemblyFileName);
}
Exploring the DC assembly for the following DomainComponent1
[DomainComponent]
public interface DomainComponent1 {
string Email { get; set; }
string Twitter { get; set; }
}
public override void Setup(XafApplication application) {
base.Setup(application);
XafTypesInfo.Instance.RegisterEntity("Manager", typeof(DomainComponent1));
We find out that XAF creates on the fly the next Manager class which is a simple XPO persistent object and is specific to our DomainComponent1 (see RegisterEntity method above).
This is really great! We already know how to Dynamic member aliases from Application Model and we can apply the same technic to the Manager class which very conveniently is related only with DomainComponent1. However there is a small problem, although the Dynamic member aliases from Application Model will successfully create the members in the Manager class, XAF does not know their existence. In next section we will discuss how to workaround this.
The TypesInfo system
- XAF works with object types, so the XAF team introduced the TypesInfo, a wrapper around .NET Reflection. For UI creation and for all metadata operations XAF uses the TypesInfo system. In addition the TypesInfo system allows metadata modification with code as easy as it can be! The power is there my friends, because the UI is automatically generated by querying types and members from TypesInfo.
- XAF supports by default XPO and Entity Framework but is possible to support a custom ORM as well. To make this possible XAF team architecture a separate interface the ITypeInfoSource, which holds all Type metadata (e.g. for XPO-> XpoTypeInfoSource).
UI + business logic <— TypesInfo –> XpoTypeInfoSource OR EFTypeInfoSource OR any ITypeInfoSource.
In short the above theory leads to the conclusion that the XpoTypeInfoSource will be asked from XAF to provide the Type members for any class. Therefore, we only need to override the EnumsMembers method of XpoTypeInfoSource to provide our own implementation! Bellow you see a part of this implementation, you can find the rest in the sample at the end of the post.
public class XpandXpoTypeInfoSource : DevExpress.ExpressApp.DC.Xpo.XpoTypeInfoSource, ITypeInfoSource {
void ITypeInfoSource.EnumMembers(TypeInfo info, EnumMembersHandler handler) {
EnumMembers(info, handler);
Type type = info.Type;
if (TypeIsKnown(type)) {
if (type.IsInterface) {
EnumDCInterfaceMembers(info, handler);
}
}
}
Wasn’t this amazingly fast and simple? I always emphasize that XAF has 2 advantages
- It is well architectured –> overridable.
- It is well architectured –> reusable.
Based on the above 2 assumptions you can download and use the DynamicMemberAliasesForDC.zip 
.
We are happy to read your feedback about this!. Remember that your questions are the best candidates for future posts.
P.S. : eXpandFramework users only need to register the Core modules (see How to use an eXpand module with an existing XAF application)
Until next time, happy XAF’ing!
