XAF - 10 - Advanced data layer features

This is post no. 10 in the mini series "10 exciting things to know about XAF". You can find the announcement of the series here.

I've reached the last post in the mini series, and this is going to be about the functionality XAF inherits from the underlying infrastructure that our ORM product XPO provides. For a start, this is where XAF gets its compatibility with a vast number of different database systems from.

There are two different ways of changing the database type XAF connects to. The very easy approach, which we've implemented for a few of the most common backends, is to use the connection components in the Application Designer within Visual Studio. For backends that aren't directly supported by a connection type in the Designer, you must configure the connection string in the app.config and/or web.config file(s) manually.

Of course it is important to know what connection strings you need to use. Generally I guess if you're using a particular RDBMS, you are probably more familiar with the connection string format it uses than I am, so in reality it's probably not a big problem. Your RDBMS docs should give you details, as well as online sources like http://www.connectionstrings.com/. For the purpose of using the connection strings with XPO/XAF, there's one other thing that's important though: the connection string format must be recognizable by our libraries, so they know what database type to connect to. There's a pretty useful heuristics at work to figure this out, but sometimes connection strings look so similar that the distinction isn't easy.

For that reason, we have introduced a flag called "XpoProvider" into the connection string, which tells XPO explicitly which connection provider it has to use. The other extremely helpful thing is that all XPO connection providers have a helper method GetConnectionString, which takes a few typical parameters and generates a correct connection string, including the XpoProvider flag, for you. To take advantage of this, create a new Console Application project and add references to DevExpress.Data, DevExpress.Xpo and, if your provider is one of the less common ones, DevExpress.Xpo.<version>.Providers. The namespace DevExpress.Xpo.DB now has all the various Connection Provider classes, and you can output valid connection strings on the console like so:

Console.WriteLine(MSSqlConnectionProvider.GetConnectionString(".", "mydb"));
Console.WriteLine(MySqlConnectionProvider.GetConnectionString("localhost", "user", "password", "database"));
Console.WriteLine(PervasiveSqlConnectionProvider.GetConnectionString("localhost", "user", "password", "database"));

This example will render the following output:

 
XpoProvider=MSSqlServer;data source=.;integrated security=SSPI;initial catalog=mydb
XpoProvider=MySql;server=localhost;user id=user; password=password; database=database;persist security info=true;
XpoProvider=Pervasive;Server=localhost;UID=user;PWD=password;Data Source=database;

In addition to this, XPO also supports connecting to a service of some description, over a remote connection. Over time I've written a whole lot of blog posts on this topic, which I recommend you read if you're interested in this scenario. Here's the main XPO blog, which you should probably read through yourself. Here's an incomplete list of the interesting posts on the subject:

• XPO is good for distributed applications
• Using .NET Remoting with XPO
• Using Web Services with XPO - also read this followup
• Announcing the XPO Publication Service - further information on that one here and here
• XPO Publication Service updated for 8.1.4
• XPO and RemObjects
• XPO and WCF

The connection strings that make XPO connect to XML Web Services and .NET Remoting are also supported by XAF directly.

Finally, if you want to influence the way the XPO connection is set up and do things you can't specify through the connection string, it is possible to hook into the process of setting up the XPO connection provider and data layer. To do this, you override the method OnCreateCustomObjectSpaceProvider in your WinApplication and/or WebApplication class(es) and return your own version of an ObjectSpaceProvider. It isn't hard to derive your own ObjectSpaceProvider from one of the standard ones and handle data layer creation in any way you see fit -- if there's interest in this and reading the source of ObjectSpaceProvider.cs doesn't help you, leave a comment and I'll try to create a sample when I have time.

Some other interesting features of XPO that you could enable or configure using this approach are the data layer caching and SqlDependency features. Of course you can switch on SqlDependency support by using the right XpoProvider flag, as described in the article, and this also enables data layer caching. But SqlDependency is a special feature for SQL Server support, and setting up data layer caching for other backends currently requires the OnCreateCustomObjectSpaceProvider approach outlined above.

So, that's all I have to say today. I hope the series was interesting -- I'll hand the post on styling ASP.NET applications in as soon as it makes sense, again my apologies for that one. I'm almost on my way to TechEd now -- if you're there, say hi!

Free DevExpress Products - Get Your Copy Today