It is a common understanding that the Object-Relational Mapping solutions are used mostly for saving development time. It is also quite obvious that the more simple and standard your data layer is, the more time you would save by automating its creation using the code generation and runtime capabilities that most ORMs on the market are offering. The question is – should you consider using an ORM for situations that are not that standard? For instance, you might need to define types dynamically during runtime, fine-tune your performance on ADO.NET level, customize the data layer classes, or work in a distributed environment where data caching could be problematic. Each of these issues can become the reason to switch to a custom, in-house development approach, unless your ORM has the solutions and customizations available. In this article I will describe why I would still consider Telerik OpenAccess ORM regardless of these complications, and why you can rely on its flexibility.
1. Proof of Concept - Telerik Sitefinity
First of all, I already have the proof of concept – OpenAccess ORM is fully utilized by a leading player on the Online Business Platforms market – Telerik Sitefinity
. The specific needs that such a system has make it virtually impossible to use a less flexible ORM solution.
2. Artificial Types and Properties
One of the major reasons for Sitefinity to use OpenAccess ORM is the ability to define the so called Artificial Types and Properties during runtime, map them to existing tables or create new tables for them, and execute CRUD operations dynamically. For more information how this process works, download for free the OpenAccess Samples Kit and find there the “Consuming Types Defined during Runtime” sample.
3. Bulk Update and Bulk Delete
Usually ORM solutions work on an entity-by-entity basis, where mass operations for updating or deleting multiple records are either not possible, or achieved through custom SQL statements. In OpenAccess ORM however, I can execute such statements using an easy LINQ-like syntax for specifying the bulk operations, so I can avoid the SQL scripting, while in the same time remaining free to change the back-end without rewriting my code!
4. Streaming Just because I am using an ORM, that
doesn't mean I have to load large files from the database entirely in memory. With OpenAccess, I can map a column to a stream and load the data on configurable chunks, optimizing my memory consumption. Open the Streaming Videos Using OpenAccess sample in the Samples Kit and see for yourself!
5. Profiling and Tuning
Instead of using OpenAccess as a black-box, I can track what is going on and tune my queries using the OpenAccess Profiler and Tuning Advisor. Unlike the SQL Profiler, which shows me only the final SQL statements on the database server side, the OpenAccess Profiler tracks what OpenAccess ORM is posting to the database from the application server side, which could be quite useful. Moreover, it automatically suggests improvements when it detects that my LINQ queries can be optimized!
6. Low-level API
No ORM runtime can fit all data access needs 100% automatically. I need to know that if nothing else fits my requirements, I can still use customized queries to implement something specific. However, I prefer to do that within the ORM, instead of having the complexity of two channels for reaching the database. This is exactly what the OpenAccess ADO API is doing - it allows me to easily mix the mapping part of my data access with customized executions of queries, stored procedures and functions, so that nothing is beyond my reach.
7. Back-end Independent Mapping
For complex applications with millions of lines of code, I am always concerned that decisions taken today might turn out to be wrong one year from now, but I won’t be able to reverse them easily. For instance, I can start with a small local database such as SQLite or LocalDB, but in time the application grows or the company policy changes and I need to migrate to Oracle. The SQL data types of the different databases are not matching, so I would have to redefine my mapping all over again, unless I use the Backend Independent Mapping feature of the OpenAccess Fluent API. It allows me to specify the types in a generic way and the migration becomes much easier.
8. L2 Caching in Distributed Environments
OpenAccess ORM offers me Level 2 caching out of the box. Furthermore, in case I need to synchronize it in distributed environment, I don't have to write all the code by myself - I can simply use MSMQ and synchronize my L2 cache
9. Connection Pooling
In complex applications with many parallel points of connection to the same database, it is critical for me to have mechanisms to optimize the connection opening process by configuring Connection Pooling based on my specific needs. This is exactly what OpenAccess ORM is offering - 3 different modes and many additional options for fine-tuning the connection pooling process
10. Tech Support
If there is something wrong with my data access layer, my entire application suffers. In those cases I just wish I have the reassurance of an international company where proficient data access developers are at my disposal to help me locate and resolve any issues with the ORM of my choice, in a minimum time-frame. Currently OpenAccess ORM is offered as a part of the DevCraft Ultimate Collection including 24h ticket replies, phone support and remote web assistance, apart from the huge documentation and other online resources for self-servicing. Even if those channels are not enough and I feel my team has more specific needs, I can count on Telerik to deliver the training or project assessments I need.
I hope that the list is informative for you to assess some of the specific and unique features Telerik OpenAccess ORM is offering. Do not hesitate to provide me your feedback - what features are you frequently implementing in your complex data access layers and how OpenAccess ORM can help you develop them easily?