1

I am working on an ASP.NET MVC web application that was built with DevExpress 12.1 tools including DevExpress XPO.

Due to licensing issue, I have task in which I want to remove Devexpress components entirely from that web application.

After r&d, I found at the first step of removing, I need to change datalayer to Entity-Framework (currently using XPO).

I know the manual process, but can anybody suggest how to do this? Is this any online tool or suggestion which achieve my work speedily?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Ajay2707
  • 5,690
  • 6
  • 40
  • 58
  • Every thing I found and no clues, my research say start with scrap. – Ajay2707 Oct 14 '16 at 05:58
  • @Ajay2787 Have you ever managed to complete this process? I'd be really interested in your experiences, especially about XPO to EF migration. I use a repository layer above XPO, hence it *could* be simpler, but still I'm connected to XPO in many points: have some custom ValueConverter; use InheritenceMapping; use enums a lot; use PostgreSQL underneath and have a customized provider for it; etc. Could you please tell us your experiences, maybe in your original post as an addition? – Zoltán Tamási Nov 03 '16 at 09:07
  • No dear, xpo to ef as I told needs start from scrap. but for xpo is better than ef when you use devexpress. For your issue ("connected to XPO in many points"), can you explain what is the exact issue you facing? – Ajay2707 Nov 08 '16 at 06:01
  • I ment I wrote a lot of custom stuff / limitation workaround / hack for it during the years, and it's kind of hard to examine all of them within EF, would need a lot of integration tests at least. On the other hand, I'm not using DevExpress controls in this project, only XPO, and as far as I can see, it brings much more limitation, for example its LINQ support still leaves something to be desired to say the very least. – Zoltán Tamási Nov 08 '16 at 07:54

1 Answers1

2

I use XPO in one application and EF Core in another. I would happily move away from XPO forever, EF Core is a much better experience - the linq to entities is way better than linq to xpo, and while there are lots of other reasons, the most important thing is that you can change properties by ID with EF Core - in XPO you have to load the object first and then change the object reference. I have begun to truly loathe working with my project that is dependent on XPO so I have been looking for an answer for this for a long time.

I have sadly come to the conclusion that the best way is a gradual migration. You can run the models side by side and just change components over on a progressive basis. This way you can keep the application functional while moving between ORMs. There is sadly no esy way to do this.

statler
  • 1,322
  • 2
  • 15
  • 24
  • That we also found at that time as a conclusion that no direct method support, we have to do step by step (page by page) migrate the code from XPO to any other traditional approach. that time we want in EF asp.net MVC. but that good that you migrate in asp.net core. – Ajay2707 Mar 21 '19 at 06:58
  • The way EF Core handles disconnected objects is a joy. – Larry Sep 16 '20 at 12:08