How to use DevExpress ORM (XPO) in an ASP.NET MVC application

ASP.NET Team Blog
25 August 2011

imageCheck out the how-to knowledgebase article below that shows you 2 different approaches to using the eXpress Persisent Objects (XPO) with an ASP.NET MVC application:

How to use XPO in an ASP.NET MVC application

 

The article will be most useful if you are already using DevExpress XPO. If you're new to DevExpress XPO then check out the Code Central solution attached to this article:

Example: How to use XPO in ASP.NET MVC3 application (Razor)

 

It's a full working solution that shows how to use XPO with ASP.NET MVC. And there is a C# and VB.NET version of that sample available. Simply click the 'programming language' dropdown and choose.

Best Practices

If you're an XPO user now then you might have wondered, "What is the best practice for using XPO in an ASP.NET MVC application?"

This knowledgebase article is your answer:

The main difficulty of integrating the eXpress Persistent Objects framework into the ASP.NET MVC application is that both these frameworks have their own approaches to create a model instance. ASP.NET MVC requires a model to provide the parameter less constructor. It simply creates a new model instance each time it is required. XPO considers every object created via public constructors as new and inserts a new record in the database associated with this object. Hence, it is necessary to prevent the ASP.NET MVC engine from creating new instances and address this task manually. We will describe two possible approaches that can be used to address this issue.

 

Why use XPO?

If you've not yet seen XPO then check out this list of feature benefits here: XPO Features & Benefits

The M in ASP.NET MVC stands model and you have a choice to use just about any .NET ORM including our own XPO.

 

Check out the 'How to use XPO in an ASP.NET MVC application' article. Then drop me a line below with your thoughts on using XPO with ASP.NET MVC. Thanks.

DXperience? What's That?

DXperience is the .NET developer's secret weapon. Get full access to a complete suite of professional components that let you instantly drop in new features, designer styles and fast performance for your applications. Try a fully-functional version of DXperience for free now: http://www.devexpress.com/Downloads/NET/

Follow MehulHarry on Twitter

Tags
2 comment(s)
Felipe R Machado
Felipe R Machado

This is required because of XPO is not exactly POCO-based, but, hey, I can live with that.. The benefits far outweigths the drawbacks in this case...

Also, I really believe that it is much better to have "presentation objects" to pass to the views instead of passing the domain objects themselves, with all the weight and logic that are tied to them... It is, in some ways, the same as writing business logic in the interface (well, it's not the same, but... So, the second solution is in fact what I would do even if I was using nHibernate, Entity Framework or even a hand-crafted ORM...

25 August, 2011
Dennis (DevExpress)
Dennis (DevExpress)

Felipe;

You can use POCO with XPO - just mark it with the PersistentAttribute and XPO will be able to persist it. However, as you said yourself, benefits of using normal persistent objects far outweighs the drawbacks (e.g. no support for associations - you will have to code it yourself in your POCO).

2 September, 2011

Please login or register to post comments.