XPO

February 2007 - Posts

  • Upcoming XPO/XtraGrid feature: server-side grouping, sorting, filtering, ...

    We have this really fantastic feature coming up in release 7.1 of DXperience, that I want to tell you about. I had a rather hard time coming up with a title for this post and it’s still rather long (the post as well as the title) – I think it’s not too hard to understand what the feature is about, but it’s hard to summarize in so few words that they fit a blog post title easily.

    One problem that people have in .NET (and actually in most other general purpose programming environments that I’m aware of) has to do with the perfect way of handling data that is stored on a server, usually in relational databases. The problem is that there is no such perfect way, and all the technologies that try to tackle the issue are usually really good for one part of the problem and really bad for another.

    Eh?

    Two of our products can be used to demonstrate the issue: XPO and the XtraGrid. Both have to do, in the widest sense, with the handling of large amounts of data. XPO deals with the questions of storage – where is that data located, how can I get it from its storage location into my application, how do I handle it once it’s there, and so on. The XtraGrid is all about interactive work with data: view it, arrange it, sort, filter and group it. So what’s the problem? It is that the two products don’t work together the way they could. XPO has great capabilities for filtering data, using criteria that are translated into SQL code. The XtraGrid does filtering, too, but at the same time it doesn’t make assumptions about the source of data that it’s working with, and so it implements its own filtering functionality. The diversity with which we are confronted in today’s programming world is the source of the problem here, and the shortcomings are most visible when the amount of data you’re working with is large.

    Let me make it clear that this is not a problem that’s particular to our products. If you’re going for standard Microsoft technology, you have the same problem – ADO.NET allows you to construct complex filtering queries, and the DataGridView has a certain degree of interactive functionality, but the two don’t work together any more than our products do. I’m sure I’m missing something, but I’ve only once before seen a product that could facilitate the kind of technical interaction of layers that I’m talking about here (hi Jason!).

    Moving along…

    Now we’ve set the stage, what is the feature? Rather simple to explain, suddenly: it’s a technology that allows our grid to make use of the server-side functionality that XPO (or any other data layer) exposes. Interactive sorting of data in the grid is automatically translated into an “order by” that is executed on the server. Same for grouping and filtering, and the XtraGrid never retrieves more information than it actually needs.

    At the center of our implementation is a new interface, IListServer, that the XtraGrid can use if configured to do so. XPO 7.1 comes with a component called XPServerCollectionSource, which implements this interface. Hooking the whole thing up is easy: drop an XPServerCollectionSource on your form and configure it, very similar to an XPCollection. Bind the XtraGrid and set the GridControl.ServerMode property to true – done. Easy, isn’t it? From now on the XtraGrid will call the methods of IListServer each time one of the critical operations must be performed on the data, and the XPServerCollectionSource uses the XPO infrastructure to have the operation executed server-side.

    Of course it is possible to implement IListServer yourself, and we will possibly provide other such implementations in the future. So the feature is not inherently an XPO only thing – we had to start somewhere. Go ahead and have a look once 7.1 becomes available – your own implementation could be the first.

    Great, I'm going to use that all the time...

    Well, you probably shouldn’t. As nice as it is, it comes with a few drawbacks that I also want to tell you about. Here’s a quick and possibly incomplete list:

    • Grouping, sorting and filtering work on the server. Haha, I hear you say, you just said that was a good thing. Well, yes it is, but at the same time it can be a problem – there are a number of events in the XtraGrid, that allow you to influence how these functions are performed. But not any longer, when server-side functionality is employed for the purpose. In that case the rule for these functions is: your client can’t do what your server can’t do.
    • Out of the box, it works only with XPO. Personally I like that, but granted, there are people out there who don’t use XPO. That’s why we developed the architecture in such a way that it would be possible to provide a solution to these people as well – the solution itself is not available yet.
    • The implementation of the XPServerCollectionSource doesn’t currently support write access. This is in our plans for future development, so it’s not intended final behaviour. Nevertheless an important thing to know for the time being.

    Summary

    A great and very interesting feature, that’s what I think. It has the potential to greatly enhance performance in those cases where large amounts of data need to be handled in an interactive control. It’s AJAX for Windows Forms, is what one of our developers said. It’s a virtual grid mode based on a single interface, if you like that metaphor better. In any case I think it’s very powerful technology and we probably haven’t realized yet what potential this abstraction has. Be sure to try it out and let us know what you think.

    I’m going to take a short break next week – please do leave comments, but be aware that I’ll reply only when I get back.

  • XPO Simplified property syntax - a summary

    It’s been a while since we introduced a feature called “simplified property syntax” to XPO. At the time I posted some information about it to the newsgroup, but there have been developments, changes and inconsistent statements about the whole topic, so I thought it would be good to summarize the information in one place.

    So what is that simplified syntax we’re talking about? That’s rather easy: we have introduced a number of helper methods in our XPBaseObject class, which allow you to use a shorter form for property implementations. We have previously recommended a certain form for property implementations in persistent classes – see this article, the section titled “Automatic collection of changes” – and this new simplified form takes care of the notification requirement described in that article while providing a concise syntax at the same time.

    There are several use cases of the helper functionality we provide, and I want to describe each of them on its own.

    Case 1 – automatic value storage, simple syntax – not recommended

    public class Person : XPObject {
      ...
    
      public DateTime Birthday {
        get { return GetPropertyValue<DateTime>(); }
        set { SetPropertyValue(value); }
      }
    
      ...
    }
    

    Now, I’m sure this is very close to the shortest form anybody can imagine for a property implementation. Originally we were planning to recommend this form, with a caveat: there’s a certain performance overhead involved in the algorithm that determines the name of the property behind the scenes – as you can see, that name is not passed into the GetPropertyValue and SetPropertyValue methods, so to do anything useful, XPO has to figure it out itself. Our thought was that in many cases this overhead would be offset by the productivity gain of the simple syntax.

    Now we recently found a technical problem that makes this approach more problematic. The issue is in our algorithm that analyzes the call stack to find the name of the property being used – there are cases where this just doesn’t work, apparently because the .NET 2 compiler employs improved mechanisms of inlining method calls.

    In case you have already implemented this approach, I’m sorry to say that we will probably not be able to fix the problem itself. We do have instructions for a workaround, so that you can be sure your implementation will not start to malfunction. There are two things you can do, alternatively:

    1. In any assembly that has persistent classes that use the syntax above (or any other related syntax where the property name is not passed in explicitely), add the following assembly level attribute: [assembly: System.Diagnostics.Debuggable(true, true)]
    2. Add the following attribute to each property getter and setter that calls one of our methods with this syntax: [MethodImpl(MethodImplOptions.NoInlining)]

    In any case let me repeat, the technical issues combined with the performance problems earn this approach the label Not Recommended.

    Case 2 – automatic value storage, recommended syntax

    public class Person : XPObject {
      ...
    
      public DateTime Birthday {
        get { return GetPropertyValue<DateTime>("Birthday"); }
        set { SetPropertyValue("Birthday", value); }
      }
    
      ...
    }
    

    This approach is similar to case 1 above in that it uses automatic storage of the property value (the same functionality that is otherwise exposed via the GetMemberValue and SetMemberValue methods), but the name of the property is being passed in explicitely. Thereby it avoids the performance problem as well as the technical issue of case 1. This approach can be recommended, it has only one drawback: there’s no local variable for the value storage, so if you have business logic implemented in the class and you want to access the value of the field, you always have to go through our helper methods. This may of course, in turn, introduce a performance issue.

    Note: While writing this article, I discovered that one of the overload of the GetPropertyValue method that is used in the sample above, does not actually exist – or rather, it has been removed accidentally. This is true for versions up to 6.3.3 – I haven’t looked in which version this overload disappeared. We are going to add the overload back in of course, until then you’ll have to use this of this format instead: return (DateTime) GetPropertyValue(“Birthday”);  In other words, the non-generic version of the method is available, the generic one isn’t.

    Case 3 – local variable storage

    public class Person : XPObject {
      ...
    
      private DateTime birthday;
      public DateTime Birthday {
        get { return birthday; }
        set { SetPropertyValue("Birthday", ref birthday, value); }
      }
    
      ...
    }
    

    This is now simple to explain: a local variable is being used to store the field value, and yet another overload of SetPropertyValue is called (once more including the name of the property in the parameter list) to set it. This approach doesn’t have any drawbacks, so it is recommended.

    Summary

    In all the cases where SetPropertyValue is being used, the syntax is relatively concise compared with the samples we published earlier in relation to the notification requirement for property setters (again, see here for the explanation of that requirement). The SetPropertyValue method, regardless of the overload you use, performs the notification for you. A variant of the approach (case 2) can use automated storage for those cases where you don’t need quick access to a local variable. We recommend you use case 2 or case 3 depending on your needs.

    Once again, we don’t recommend you use the syntax described for case 1 above – it may work for you in certain circumstances or when taking good care and applying the necessary workarounds, but the performance of the approach is a problem in any case.

LIVE CHAT

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

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. 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-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners