Search This Blog

Thursday, December 25, 2014

Looking for practical experiences with both DevExpress XPO & ADO.NET Entity Framework

You know that XAF supports both ORM libraries to almost the same extent, so there is no noticeable difference at the framework level (see 1, 2, 3) that should affect your choice in favor of a certain data access tool. There are, however, some differences between these ORMs in their functionality, usability, history and other factors which may indirectly affect your choice.

We do not provide comparisons of our products with competitors (mainly from an ethical point of view), but I think it would not hurt anyone if there was a list of proven opinions from users who had practical experience with both ORM tools. I already started collecting this list and among differences our users mentioned was, for instance:

  • Lower technical support level for EF (it's provided by the community through and forums) than for eXpress Persistent Objects (XPO) provided by DevExpress support team
  • Several guys mentioned that they did not like massive API changes during EF evolution in the past years, which increased maintenance costs. BTW, it is interesting what will these guys say about the upcoming EF7 breaking changes:-)
  • On the other hand, certain people like LINQ more than the criteria language (LINQ to XPO is also supported, but in XAF, you had to use CriteriaOperator as a common denominator for querying data as it can be easily serialized as a string). 
  • Also, XPO supports a broader range of database engines out-of-the-box (to tell you a secret, non-XAF Windows Workflow Foundation users who are longing for Oracle or other DB support regularly come to us due to our Worklow Instance Store powered by XPO). Although there are also many custom db providers for EF (e.g., from Devart), they may be paid.
  • Several users think that in their opinion, DevExpress ORM is easier to get started with and use than EF, which does not provide built-in change notifications, like XPO persistent properties do. On the other hand, there are some free extensions like that achieve a similar effect. 
  • Many XPO users love dynamic runtime extension of persistent classes through XPDictionary for additional flexibility in the object model. Check out How to create persistent metadata on the fly and load data from an arbitrary table for more details.
  • Many XPO users also find it more mature and feature rich as compared to EF (see details), although I admit that this may be very subjective, e.g. I met certain users that switched to EF due to certain missing capabilities.
  • On the other hand, EF is free and a de-facto standard for .NET developers and it is much easier to find and hire an EF developer because of a larger community and strong promotion from Microsoft. We are also looking forward polishing our EF integration and are very excited about EF 7 or whatever it is called in particular.
  • XPO has not received rich features in the last years and does not provide a good migration feature like EF does, either. Regardless, we are quite proud of XPO and all that it offers. We support it and certainly want to improve it further.

I want to emphasize that the details above are real feedback (it may be subjective) we received from our users, and overall, both ORMs are good products you can use to build production apps, and it has been proven by a lot of customers in the last decade. As anything else, each tool has its own strengths and weak points, varying a lot for each developer/experience/project.

So, back to my original request to people who have evaluated both ORM tools and can compare them based on their practical experience.

Would you please list the factors that determined your current data access technology choice? In particular, what features or non-technical factors were most important for you when choosing one ORM over the other and why? 

Please either post in comments or email me at dennis at devexpress dot com.
If I receive enough feedback from other users, I will categorize it and post it in my blog for the XAF community benefit. Thanks for your time in advance!

See Also:
1. EF7 – v1 or v7?
2. EF7 - What Does “Code First Only” Really Mean


  1. please provide more data annotation attributes like that produce 'cascading update and delete' in phisical tables.

  2. @mukhlim: would you please elaborate a bit more on your scenario and describe your current solutions, if any?

  3. if possible please add attributes like this on collection:

    [IsCascadeUpdate(true), IsCascadeDelete(true)]

    those should affect database tables phisically as we sometime need to process directly using SQL

  4. @Mukhlim: XPO already provides the Aggregated attribute for that purpose ( If your suggestion was about EF, it is better to forward it to Microsoft as we will unlikely implement this at our framework level, because this feature clearly deserves to be done at the ORM level.
    As for your last comment, I would greatly appreciate you posting an XPO example where AggregatedAttribute cannot handle what you wanted so we could be in a better position to offer you alternative technical solutions or consider ones for the XPO future if this scenario is not easily possible in the current version.

  5. well, for performance reason, we sometimes use IList instead of XPCollection. That is, [aggregated] does not work, except we have set CASCADING DELETE in the database level

  6. The advantage of code first EF is that the database relationships can be set up by overriding the OnModelCreating code of the DBContext and using FluentAPI I am hopeful that I can even get away with using the WithRequired relationship, which is very important to me. Orphan detail records are highly undesirable, and thus it is best to lock them out at the level of the SQL Server database structure

    1. @Kirsten: XPO also allows defining data model members, relationships and attributes dynamically: