News, tips, tricks and more about DevExpress Application Framework (XAF) directly from the lab: Exposing Domain Components (DC) via OData for mobile apps

Wednesday, April 3, 2013

Exposing Domain Components (DC) via OData for mobile apps

As you probably know, it is possible to use DC in non-XAF applications as described at eXpressApp Framework > Task-Based Help > How to: Use Domain Components in non-XAF Applications

So, I will use a similar approach in my XPO-based OData Service project (you can learn more on how to create it via the wizard here). Once I created the service, I will have to modify my XpoDataServiceV3 descendant as shown below:

[JSONPSupportBehavior]

public class DCDataService : XpoDataServiceV3 {

static XPObjectSpaceProvider objectSpaceProvider = null;

static readonly DataService1Context serviceContext = new DataService1Context("XpoContext",

"DevExpress.ExpressApp.DC.GeneratedClasses", CreateDataLayer()

);

protected override UnitOfWork GetSessionCore(IObjectLayer objectLayer) {

if (objectSpaceProvider != null) {

XPObjectSpace os = (XPObjectSpace)objectSpaceProvider.CreateObjectSpace();

return (UnitOfWork)os.Session;

}

return base.GetSessionCore(objectLayer);

}

static IDataLayer CreateDataLayer() {

XpoTypesInfoHelper.ForceInitialize();

var typesInfo = XpoTypesInfoHelper.GetTypesInfo();

var xpoTypeInfoSource = XpoTypesInfoHelper.GetXpoTypeInfoSource();

typesInfo.RegisterEntity("Survey" typeof(ISurvey));

typesInfo.GenerateEntities();

var connectionString = "Integrated Security=SSPI;Pooling=false;Data Source=(local);Initial Catalog=TestDb";

var dataStoreProvider = new ConnectionStringDataStoreProvider(connectionString);

objectSpaceProvider = new XPObjectSpaceProvider(dataStoreProvider, typesInfo, xpoTypeInfoSource, true);

objectSpaceProvider.CreateObjectSpace(); // Force the objectSpaceProvider.DataLayer property initialization.

XpoDefault.DataLayer = objectSpaceProvider.DataLayer;

DevExpress.Xpo.XpoDefault.Session = null;

return XpoDefault.DataLayer;

}

Here I would like to focus on three things:

1. I initialized the static serviceContext variable and provide the namespace of our auto-generated DC entities as the second parameter: "DevExpress.ExpressApp.DC.GeneratedClasses". It is important to avoid dealing with long-named entities like "DevExpress_ExpressApp_DC_GeneratedClasses_Survey" in our consumer applications.

2. I initialized the data layer that is used by my XpoContext descendant via the static CreateDataLayer method. There I used some XAF magic, which is required for DC, because domain logic methods accept the parameters of the IObjectSpace type. If I did not use DC, then I would not use the XAF classes in my data service and rather go using pure XPO stuff.

3. I overrode the GetSessionCore to use the Session created by the XAF's ObjectSpace, again for the correct work of domain logic methods. Take special note that this virtual method is available in version 12.2.8+ only (thanks to our XPO guys for implementing my request so quickly;-)). If you want to test it right away, I have included the latest version of the DevExpress.Xpo.v12.2.Extensions assembly into the demo project I posted here.

Finally, let me demonstrate why I created the OData service in the first place. Of course, I needed it for my mobile DXTREME application:

View on screencast.com »

You may also be interested in my other blog on a similar subject at http://community.devexpress.com/blogs/eaf/archive/2012/12/12/how-to-configure-the-xaf-middle-tier-security-service-and-deploy-it-in-the-cloud-for-further-use-by-desktop-xaf-and-mobile-dxtreme-clients.aspx (that one is a way more complex, though).

UPDATE:

Originally when experimenting with this DC-based service I tried to reference the DcAssembly.dll into my data service project. This cache assembly is automatically generated by XAF when running the application with no debugger attached. So, to get it, I simply ran my XAF WinForms application, which used the same data model, and then copied the generated assembly from the Release/Bin folder into my data service project. Since this assembly contains regular persistent classes instead of DC interfaces (remember my recent talk about different types?), I hoped that this way it might be easier for you to understand and work with. Unfortunately, I had to stop using this undocumented approach later, because it required additional configuration from the application for the correct operation of the DC-based functionality: normally, when XAF loads this assembly internally it also calls the private void ProcessGeneratedAssembly(Assembly generatedAssembly) method of the XpoTypeInfoSource class. Another reason is that with the DcAssembly.dll approach it would also be more difficult to deploy and maintain the app due to the overhead on generating and copying the assembly...