Building XpoLinq

Developer Express recently released first beta version of their XPO2 ORM product to their subscribers (currently there are also betas of both XtraCharts and XtraLayout – all of these betas look really good). Since I’ve already dived into Linq/DLinq world I soon missed Linq features for doing queries. Thus I couldn’t resist and started implementing it myself – hence the XpoLinq project is born. Here is an example of syntax:


RhCollection<Address> address = from a in addresses where a.City == “Nova Gorica” select a;

 

Note that Linq is used only for creating select expressions while behind the scenes runs XPO2.

 

XpoLinq syntax and has few benefits over existing Xpo CriteriaOperator syntax:

– intellisense support (a.City)

– code checking during compile time

– integrates with Linq (you can mix queries between Xml, DLinq, XLinq and any other Linq compliant subset)

 

I find all of these points above extremely useful features that should be present asap in any product that does queries. Perhaps the only problem is that Linq is still far away to being released (but it is very functional right now) and using its features for short time projects might be risky. Anyway, whether I continue work on XpoLinq is unknown depending on several factors: my time, DevExpress implementing it, my curiosity, etc. Regardless if my XpoLinq lives or not it has been certainly an interesting Linq learning experience.

8 thoughts on “Building XpoLinq

  1. Hi Miha,
    I’m curious about your XpoLink implementation.
    Do you have anything concrete that is usable?
    I’m using XPO 6.1 and am just exploring any enhancements that might prove useful.

    Thank you,

    Renaud

  2. Hi Renaud,

    I was just experimenting with Linq stuff at that time. I managed (very quickly) to enable simple scenarios and then left the thing as it was because:
    a) Mainly because Linq is in early phase (no go live on the horizon)
    b) it is the job for DX to implement it ๐Ÿ™‚ as I didn’t want to vaste too much time on stuff DX has to implement

  3. Miha, you’ve read my mind! ๐Ÿ™‚ Fascinating and very promising work you’re doing. I’m definitely on board with this direction for XPO. Now whether it becomes an extension to XPO or DevExpress incorporate/buy it from you, it has obvious value. Have you run across any show-stopping limitations due to Linq’s early state or design philosophy? I was skeptical that it could be used merely for creating select expressions, but I’m quite happy to hear this is possible.

    Do you have any more information on the status of this project? Perhaps I could offer my assistance if you think there’d be any value to it, whether code or someone to bounce ideas off.

    Please keep this project alive!

  4. BTW, I notice you use your own collection type to store the results. Is XPCollection no longer possible with XpoLinq?

    What happens to XPView in this world?

  5. Hi Dan,

    About status of the project: there is not much to say about it. Perhaps the worst problem is that Linq RTM is far far away in the future. And no, Linq is very functional and I don’t foresee any technical problem implementing XpoLinq right now – it is just for the above reason I didn’t invest much time into the thing. The second reason would be that DX will sooner or later have to build it – everybody (ORMs) will have to.
    Regarding XPCollection and XPView: there are no limitiations to use them. I use RhCollection for other reasons.

    But wait. There is another way to have strong typed elegant query language right now (some competitive ORMs have it). You would need a code generator (which XPO doesn’t have) and a proper bunch of templates (if you don’t want to type like mad)

  6. Is it something you would mind sharing with me to play around with? Has DevExpress not expressed interest yet? A year will be here before we know it (or they’ll issue a Go Live license earlier), and if we’re poised to take full advantage right out of the gate, instead of STARTING our implementation at that time, we’ll be in a much better position. Some valuable lessons could be learned between now and then about the pitfalls and limitations, or is it just so easy there’s nothing to it?

  7. Is it something you would mind sharing with me to play around with?

    It is a public knowledge: you have to abuse operator overloading.

    Has DevExpress not expressed interest yet?

    My opinion? I would say no. If DX would ship a code generator or just templates for one of the generators out there (such as CodeSmith) it would be pretty trivial to have such a query language. But since they don’t I assume they are not that interested (take note that this is just my opinion). Actually i am writting an article about XPO weak points (being a good ORM doesn’t mean that it doesn’t have weak points) – among the points is lack of code generator.

  8. No doubt that every ORM has weakpoints, but I considered the lack of code generation in XPO to be a strength. I don’t want code bloat, thousands of lines of code that will have to get updated/regenerated every time I make a change to domain classes. But is this really necessary to support Linq?

    What’s needed is an ORM side-by-side feature comparison.

Leave a Reply