April 2011 - Posts

  • XPO – 11.1 Sneak Peek – Data caching improvements


    First, we would like to refresh your memory and return to the distant past and our old posts about data caching in XPO:

    ·        XPO is good for distributed applications

    ·        XPO Beta feature: SQLDependency support

    Today is 2011, and we are excited to announce that in v2011 vol1, we greatly improved data caching support in XPO, and added additional functionality to it, allowing this feature to leave the “beta” state.

    Want data caching via WCF Services? – Now, it’s easy!

    In the previous blog, we already demonstrated how easy it is in 11.1 to create and use WCF Services for IDataStore. If you want to take advantages of XPO data caching using this solution, then the only difference is in using the ICachedDataStore interface and a respective base service class that implements this interface – CachedDataStoreService.

    Let’s demonstrate it in action (the exact steps on how to add a data store service can be taken from the previous blog):

      1: using DevExpress.Xpo;
      2: using DevExpress.Xpo.DB;
      3: …
      4: public class Service1 : CachedDataStoreService {
      5:     public static ICachedDataStore MainDataStore;
      6:     static Service1() {
      7:         string connectionString = MSSqlConnectionProvider.GetConnectionString("localhost", "ServiceDB");
      8:         IDataStore dataStore = XpoDefault.GetConnectionProvider(connectionString, AutoCreateOption.DatabaseAndSchema);
      9:         MainDataStore = new DataCacheRoot(dataStore);
     10:     }
     11:     public Service1()
     12:         : base(MainDataStore) {
     13:     }
     14: }

    Of course, some modifications of the service binding in the web.config file are necessary as well:

      1: <system.serviceModel>
      2:  <services>
      3:    <service name="WcfService1.Service1" behaviorConfiguration="WcfService1.Service1Behavior">
      4:      <!-- Service Endpoints -->
      5:      <endpoint address="" binding="basicHttpBinding" contract="DevExpress.Xpo.DB.ICachedDataStoreService">
      6:        <identity>
      7:          <dns value="localhost"/>
      8:        </identity>
      9:      </endpoint>
     10:    </service>
     11:  </services>
     12:  <behaviors>
     13:    <serviceBehaviors>
     14:      <behavior name="WcfService1.Service1Behavior">
     15:        <serviceMetadata httpGetEnabled="true"/>
     16:        <serviceDebug includeExceptionDetailInFaults="false"/>
     17:      </behavior>
     18:    </serviceBehaviors>
     19:  </behaviors>
     20: </system.serviceModel>

    Fortunately, the client part does not need to be modified, because in our example, the service’s name did not change, and in addition, the “data caching domain” of our service is automatically detected by XPO.

    Data caching configuration

    After looking at how easy it is to implement, you may naturally ask how flexible it really is. Of course we did not forget about flexibility!

    For example, it is possible for you to configure which tables need to be cached and which ones don’t. This option can be useful for tables, which are frequently changed – if they are changed a lot, it makes no sense to cache them. The code below demonstrates how the service above can be modified to configure the DataCacheRoot, to cache only the “Customer” table:

      1: using DevExpress.Xpo;
      2: using DevExpress.Xpo.DB;
      3: using DevExpress.Xpo.DB.Helpers;
      4: …
      5: public class Service1 : CachedDataStoreService {
      6:     public static ICachedDataStore MainDataStore;
      7:     static Service1() {
      8:         string connectionString = MSSqlConnectionProvider.GetConnectionString("localhost", "ServiceDB");
      9:         IDataStore dataStore = XpoDefault.GetConnectionProvider(connectionString, AutoCreateOption.DatabaseAndSchema);
     10:         DataCacheRoot dataCacheRoot = new DataCacheRoot(dataStore);
     11:         dataCacheRoot.Configure(
     12:             new DataCacheConfiguration(DataCacheConfigurationCaching.InList, "Customer")
     13:         );
     14:         MainDataStore = dataCacheRoot;
     15:     }
     16:     public Service1()
     17:         : base(MainDataStore) {
     18:     }
     19: }

    Leveraging SQLDependency

    Another configuration option for data caching we would like to tell you about is using SqlDependency feature of MS SQL Server (see here for the background on that). Again, a modified service class demonstrates how this can be done:

      1: using DevExpress.Xpo;
      2: using DevExpress.Xpo.DB;
      3: using DevExpress.Xpo.DB.Helpers;
      4: …
      5: public class Service1 : CachedDataStoreService {
      6:     public static ICachedDataStore MainDataStore;
      7:     static Service1() {
      8:         string connectionString = MSSqlConnectionProvider.GetConnectionString("localhost", "ServiceDB");
      9:         MSSqlConnectionProvider dataStore = (MSSqlConnectionProvider)XpoDefault.GetConnectionProvider(
     10:             connectionString,
     11:             AutoCreateOption.DatabaseAndSchema
     12:         );
     13:         MainDataStore = (ICachedDataStore)MSSql2005SqlDependencyCacheRoot.CreateSqlDependencyCacheRoot(
     14:             dataStore,
     15:             new DataCacheConfiguration(DataCacheConfigurationCaching.InList, "Customer"),
     16:             out objectsToDispose
     17:         );
     18:     }
     19:     public Service1()
     20:         : base(MainDataStore) {
     21:     }
     22: }

    That’s it for this blog. Do you like what you see? Please let us know with your comments!

    And happy XPOingWinking smile, as always!;-)

  • XPO – 11.1 Sneak Peek - WCF services for IDataStore

    In XPO v2011.1 vol 1, we added support for WCF Services. These improvements provide the capability to create service and client for IDataStore as easy as it can only be.

    In order to support this feature, the DevExpress.Xpo assembly will reference assemblies from .NET 3.0. Unfortunately, Visual Studio 2010 does not allow building projects whose Target Framework is set to 2.0, if they reference .NET 3.0 assemblies. To bypass this, it is necessary to set Target Framework to 3.0. Quite surprisingly, other Visual Studio versions do not demonstrate the above problem.
    This does not mean that an application will not work on a machine that has only .NET 2.0 installed on it. If the project does not use the functionality of .NET 3.0, it will work just as before. Therefore, it should not affect your clients’ installations at all.

    Let’s learn more about the implemented feature from a simple example.
    For the beginning, we will create a new WCF Service Application project. Then, we will add references to the DevExpress.Data and DevExpress.Xpo assemblies and remove files with auto-generated interfaces for the service.

    The next step is modifying the service class as follows: 

    using DevExpress.Xpo;

    using DevExpress.Xpo.DB;

    namespace WcfService1 {

        public class Service1 : DataStoreService {

            public static IDataStore DataStore;

            static Service1() {

                string connectionString = MSSqlConnectionProvider.GetConnectionString("localhost", "ServiceDB");

                DataStore = XpoDefault.GetConnectionProvider(connectionString, AutoCreateOption.DatabaseAndSchema);


            public Service1()

                : base(DataStore) {




    To finish with the service, we will need to change some binding properties in its web.config file:



            <service name="WcfService1.Service1" behaviorConfiguration="WcfService1.Service1Behavior">

                <!-- Service Endpoints -->

                <endpoint address="" binding="basicHttpBinding" contract="DevExpress.Xpo.DB.IDataStoreService">


                        <dns value="localhost"/>







                <behavior name="WcfService1.Service1Behavior">

                    <serviceMetadata httpGetEnabled="true"/>

                    <serviceDebug includeExceptionDetailInFaults="false"/>





    Now our service is ready, and it is time to implement the client part.
    For the client, we will add a Console Application into our existing solution. Then, we will use the Persistent Object item template for a  Customer class:

    using DevExpress.Xpo;

    namespace ConsoleApplication1 {

        public class Customer : XPObject {

            public Customer(Session session) : base(session) { }

            string _CompanyName;

            public string CompanyName {

                get { return _CompanyName; }

                set { SetPropertyValue("CompanyName", ref _CompanyName, value); }


            string _CompanyAddress;

            public string CompanyAddress {

                get { return _CompanyAddress; }

                set { SetPropertyValue("CompanyAddress", ref _CompanyAddress, value); }


            string _ContactName;

            public string ContactName {

                get { return _ContactName; }

                set { SetPropertyValue("ContactName", ref _ContactName, value); }


            string _Country;

            public string Country {

                get { return _Country; }

                set { SetPropertyValue("Country", ref _Country, value); }


            string _Phone;

            public string Phone {

                get { return _Phone; }

                set { SetPropertyValue("Phone", ref _Phone, value); }




    The final step is to modify the Main() of our console application as shown in the code below:

    using System;

    using DevExpress.Xpo;

    using DevExpress.Xpo.DB;

    namespace ConsoleApplication1 {

        class Program {

            static void Main(string[] args) {

                XpoDefault.DataLayer = XpoDefault.GetDataLayer("http://localhost:64466/Service1.svc",


                XpoDefault.Session = null;

                using (UnitOfWork uow = new UnitOfWork()) {

                    using (XPCollection<Customer> customers = new XPCollection<Customer>(uow)) {

                        foreach (Customer customer in customers) {

                            Console.WriteLine("Company Name = {0}; ContactName = {1}", customer.CompanyName, customer.ContactName);




                Console.WriteLine("Press any key...");





    As you can see, we pass the address of our service into the GetDataLayer method of the XpoDefault class. It is very similar to what was already supported for Web Services.

    Now if we run the service and client parts, we will see the following output:
    Take special note that the port number in the connection string may be different. You can check it in the properties of the service project in the Solution Explorer:

    Happy XPOing!


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners