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.
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!
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!
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.
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.
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?