Ask any technical architect whether they have given their team the following requirement for Data Access Layer, the answer will be resounding yes.

One of the main reasons that I also started to give this mandate to my team is that some of my customers wanted to switch to open source database like MySQL, PostgreSQL, MongoDB and others because of licensing cost and increasing cost in support. In one such instance we did lot of rework in the application written in 2009 to make it work with MySQL instead of MSSQL server.

Before proceeding with DevExpress XPO I will provide a brief outline of how data access layer evolved in .NET over the last decade. This will help young professionals to undertake maintenance of existing projects written in older version of .NET or understand legacy code to rewrite it using new features of .NET.

The plain ADO.NET was the first provided option for developers to work with various types of databases like MSSQL Server, MS Excel, MS Access, Oracle and few other databases. The code written was lengthy and raw and had lot of SQL commands inside them. Developers had to be proficient in SQL as well to develop data access layer. Some applications I worked on even had dynamic SQL generation methods.

Microsoft provided some reusable libraries for database access through its enterprise libraries which is a fantastic set of library and most of the applications that I developed from the scratch I used those libraries.

In .NET 3.5 Microsoft provided LINQ-to-SQL that relieved a big burden on developers to not learn SQL and made the code cleaner with just .NET code and not much of SQL embed into it. This also acted as primitive ORM (Object Relational Mapping). There were some bugs when the LINQ-to-SQL feature emitted improper SQL and inefficient SQL for the methods. Each table or view is generated as a .NET class and stored procedures are wrapped to be called from a .NET class method.

In later version of .NET, Microsoft released a full-fledged ORM framework that is still one of the best ORMs in .NET platform. There are also other ORMs for .NET like nHibernate which is a port of Hibernate ORM from Java world. Entity framework also came with  GUI designer that worked well with MS SQL server and made developers design database schema using Code First approach easily and productively. The challenge that developers faced with Entity Framework was its support with other databases like MySQL and MongoDB. The GUI designer was not available for some of the database types and did not work properly with some database types.

Coming back to the main topic of the blog DevExpress XPO, this ORM framework from DevExpress is something that caught my attention recently as they listed the different types of databases that this library will work with. You can see the full list of databases that this supports here. I highly recommend you watch the video below from DevExpress YouTube channel.

In a nutshell what impressed me the most about DevExpress XPO are the following.

• Support for .NET Core and Linux and Visual Studio Code. This will be of huge benefit to clients who want to write some batch programs in Linux for some of their supporting applications like batch programs.
• Support for 14 database types for your application. If your applications needs to connect to multiple types of databases then XPO is a wonderful choice. I am expecting DevExpress to add their support to NoSQL database like MongoDB soon.
• Caching features are awesome to increase performance and reduce load on database.
• Very good transaction management and support for stored procedures and views.

The most valuable feature is a GUI designer to design the objects for XPO visually like Entity Framework designer. Good luck using DevExpress XPO and if you have any questions post it on my social channels or chat with me on this website.

If you have read this post till the end then you have a surprise from DevExpress XPO.