Updated 2/9/2013
see end of post
Even though XAF does not support the idea of Domain Components + Calculated properties + Application Model out-of-the-box, XAF is still designed with the highest of standards. In this blog, I will demonstrate hot to achieve this concept of Domain Component + Calculated Properties + Application Model otherwise.
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:
publicpartialclassDynamicMemberAliases2WindowsFormsApplication : WinApplication {
protectedoverridestringGetDcAssemblyFilePath() {
returnPath.Combine(AppDomain.CurrentDomain.SetupInformation.ApplicationBase, DcAssemblyFileName);
}
Exploring the DC assembly for the following DomainComponent1
[DomainComponent]
publicinterfaceDomainComponent1 {
stringEmail { get; set; }
stringTwitter { get; set; }
}
publicoverridevoidSetup(XafApplication application) {
base.Setup(application);
XafTypesInfo.Instance.RegisterEntity("Manager", typeof(DomainComponent1));
We find that XAF creates the next Manager class on the fly and that this class is a simple XPO persistent object and is specific to our DomainComponent1 (see the RegisterEntity method above).
This is really great! We already know how to create Dynamic member aliases though the Application Model and we can apply the same technique to the Manager class, which is very conveniently related only to the DomainComponent1. However, although the Dynamic member aliases can be successfully created in the Manager class, XAF would not know of their existence. In the next section we will discuss how to workaround this.
The TypesInfo system
- In XAF, everything is an object. To help resolve object types, we created a TypesInfo system. XAF uses it for creating UI and for all the metadata operations. Because of how XAF was designed and because of the way TypesInfo system was built, metadata modification could be done easily.
- By default, XAF supports two ORM framework, XPO and Entity/ In addition, it is possible to integrate a custom ORM system. To make this possible, a separate interface, the ITypeInfoSource, which holds all the type metadata is available.
UI + business logic <— TypesInfo–> XpoTypeInfoSource OR EFTypeInfoSource OR any ITypeInfoSource.
Now we know that the XpoTypeInfoSource will retrieve Type members for any class from XAF. Therefore, we only need to override the EnumsMembers method of the XpoTypeInfoSource to provide our own implementation! Bellow is an excerpt of this implementation you can find the rest in the sample at the end of the post.
publicclassXpandXpoTypeInfoSource : DevExpress.ExpressApp.DC.Xpo.XpoTypeInfoSource, ITypeInfoSource {
voidITypeInfoSource.EnumMembers(TypeInfo info, EnumMembersHandler handler) {
EnumMembers(info, handler);
Type type = info.Type;
if (TypeIsKnown(type)) {
if (type.IsInterface) {
EnumDCInterfaceMembers(info, handler);
}
}
}
No doubt you too find this quick and simple? I always emphasize that XAF has 2 main advantages
- It is well architectured –> overridable.
- It is well architectured –> reusable.
And since it is overridable and reusable you can download and use the DynamicMemberAliasesForDC.zip
.
We are happy to read your input about this!. Remember that your questions are the best candidates for future posts.
P.S. : The 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!
Updated 2/9/2013
In the next video, I demo how to create a calculated property in runtime.