DXperience, XPO and XAF

I keep getting questions on my latest thoughts about these DevExpress products: DXperience, XPO and XAF.

Here is the summary of my personal approach on the subject (it comes from the experience of working with XAF inside-out and delivering xLim projects with DXperience and XPO into the production).

DXperience

This is a really nice component suite that features beautiful Windows.Forms controls with multiple skins. GridView, PivotGrid and XtraLayout controls are really flexible and nice (support for filter building and server-side query execution is nice, using layouts for designing UI that targets multiple platforms may have some potential). Reporting is useful but not outstanding.

Current drawbacks include:

• controls leverage PInvokes heavily and can't be used on Linux except in rare mythical scenarios with Mono + wine
• DevExpress hesitated to jump onto the WPF wagon and is quite lagging behind

DevExperience works tightly with XPO. This is an advantage in scenarios including these technologies and a slight drawback in other situations.

XPO

eXpress Persistent Objects is a starter-level ORM developed by DevExpress. It supports multiple database engines and is really easy to get started with. Yet, it has some drawbacks that were important for me:

• XPO is not known for efficient queries or ability to fine-tune them for batching and paging scenarios.
• criteria language is not strongly-typed (minus for me), while LINQ support is not complete
• XPO tends to bit rather chatty on its own, this does not work out well when server is in USA and client is in China or Russia.
• generally XPO was made with the preference for simplicity of usage instead of the flexibility and robustness. This did increase development friction for me a lot.

XAF

eXtensible Application Framework is a framework for building simple information management solutions. It is built on top of DXperience and XPO and inherits their drawbacks and strong sides: nice looks, support for multiple databases and simplicity of initial development. Basically that's Microsoft Access on a hype.

So if your projects fit into the scenario where Microsoft Access would work, then XAF would most likely work there.

Yet, if you suspect that the development might be more complex than that or might run longer than 3 months, then I strongly encourage you to evaluate XAF carefully before jumping into it. Its simplicity comes at the price - architecture is so tight, that developing almost anything out of the scenario meets high development friction. Business requirements always hit this boundary after some time.

PS: Personally I would hate to support and maintain a XAF application and would prefer to build another application based on xLim approach instead.

Comments

[Sean Kearon]

I have followed your articles about DevExpress and found them very useful. I agree that XPO has some quirks, but it is well integrated with the UI components and the support from DevExpress is very good. Indeed, it is this that made me finally decide to use XPO, along with support for VistaDB out of the box!

I've been using DXperience with XPO on my current project (Winforms, Windows only, embedded application database) and have had mainly good experience with the DevExpress stack. I have had a look at XAF, but do not see it in my future!

If you're interested, I have some posts on I reduced friction with XPO development by using automatic properties and one-way associations in my XPO objects - all with a sprinkle of PostSharp.

[Rinat Abdullin]

Hi Sean,

Thank you for the feedback! I agree that XPO is good for some projects (especially in one-man shop scenarios). Yet, in some specific projects (like this one), forcing XPO to work in a desired manner, would be too inefficient.