Telerik OpenAccess ORM features

Forward and Reverse Mapping

• Forward Mapping - OpenAccess allows you to start working from scratch with your object model and just creates your new relational database with an optimized data schema. You don’t need to think in relations anymore, but you still can. OpenAccess optionally allows you to define almost any kind of schema and you can influence the given names of tables or columns.
• Reverse Mapping - OpenAccess additionally allows you to start with your legacy database. The reverse mapping experience begins the minute you connect your new Visual Studio project to the legacy database using the Reverse Mapping wizard. OpenAccess recognizes the data model, data types and additional information like keys and creates the matching object model. Then you can start designing and developing your new .NET application. 
• Roundtrip Mapping - You can even change directions: any change in the object model will change optionally your schema and any change in the database can optionally change your object model.
• Dependent instances - You can attribute a relationship so that the dependent instance is automatically deleted when no reference to it exists any longer.

Support for 6 Databases - Enjoy database independence with full support for the most popular databases:

• Microsoft SQL Server
• Oracle
• MySQL
• Firebird
• Sybase SQL Anywhere
• Advantage Database Server

Deployment Flexibility, Mapping in the Middle

OpenAccess supports modifications of the database only within the scope of an active transaction. This addresses the real-world challenges of durability, consistency, atomicity and isolation. Therefore OpenAccess does not allow nor support any risks which might come from the underlying database. That’s why we support only fully transactional databases, focused on the most used databases for .NET applications. If you miss one important to you, please let us know.

OpenAccess defines a mapping in the middle: all mapping information is per default stored in the app.config file, so outside of your C#/VB code and outside of your database. This allows you not only to deploy your application with one object model and different database schemas for different deployments, it also allows to map differently for different database vendors. No need of any change in your code. Even if you don’t need this flexibility initially, it keeps your code independent. And it might even help to migrate your existing apps and databases to other, new databases (reverse map your old database/vendor and forward map it to your new ones).

Support for LINQ, OQL, and SQL Languages - With OpenAccess you got no limits, you can just use the best of all words, even combined.

• LINQ - OpenAccess supports LINQ. The major advantage of LINQ besides of its object-orientation is the compile time check of your queries - no surprises later during runtime.
• OQL - OpenAccess additionally support OQL, also an object-oriented query languages defined a long time ago by the Object Database Management Group. At first, it was there before the invention of LINQ and but now you can use it in such cases where you need to build the query at runtime dynamically.
• SQL - If you got any special to do or want to re-use some existing SQL statements, you can do it. Just use SQL and bypass OpenAccess.  To execute a query life on the database, you don’t need to write a line of code: Use the OQL browser from within your Visual Studio.

Transparent Data Access, Lazy Loading and Automatic Change Tracking

OpenAccess uses lazy loading where your application objects are filled with the data upon access. Not all fields will be filled immediately, so collection or picture fields can be deferred in their population. This has the advantage of saving memory and network bandwidth while preserving easy access – when the field’s content is needed, the data is fetched transparently from the database server. Of course, you can decide which fields are to be fetched when, and OpenAccess provides sensible defaults.

Modifications to values of the persistent fields are automatically tracked. You don’t need to notify the OpenAccess runtime system that an instance is to be written. When modifications are detected, only the necessary columns are included in the resulting SQL statements. All referenced persistent objects will be handled as well, and only complete object graphs are stored – no instance is left behind.

Visual Studio Integration - OpenAccess ORM is tightly integrated into Visual Studio, so you don’t need to change your environment nor the way you develop. It comes with various wizards to make your life easier and to visualize what you do. OpenAccess supports IntelliSense and the documentation is integrated in the Visual Studio Help system. OpenAccess works with Visual Studio 2005 and 2008, on .NET 2.0, 3.0 and 3.5, and supports both C# and VB.NET.

Disconnected API

OpenAccess unique ObjectContainer API concept has been the first ORM feature supporting disconnected data scenarios. Whether you’re thinking of mobile devices, web applications or replications - you need disconnected data management you can count on. To work with portions of your data in a disconnected mode, just take them with you. OpenAccess keeps them transactionally save and uses little network bandwidth by only exchanging the minimum change set. So it tracks which objects have been changed or are new. 

The offline ObjectContainer API shares a common interface with the online ObjectScope API, and parts of the applications can be implemented independent of their connectivity. 

The ObjectContainer serves as a bag which can hold object network, provides serialization, change tracking and the ability to apply changes in a round-trip fashion to the database.

Synchronized Distributed Level 2 Cache

OpenAccess provides a cache which can be shared by many database access instances (object scopes) in process. This is useful in situations where a lot of data is shared and commonly asked for. A typical example is a web server where much of the data is stable, sharable and commonly used.

Entries are evicted from the cache, when objects change. The cache is populated upon read access, configurable in its sizes and stored entry types and uses LRU overflow handling.

Entries in the cache are object states (representing the data of a single object) and whole query results. That means, the result of recurring queries can be stored in the cache and such queries will not hit the database server unless the cache entry is evicted. Eviction is automatic but can also be triggered manually.

Not only is such a cache shared within one process, but many of those caches can easily be coupled over the network to provide a distributed synchronized cache. The key benefit is that the Level 2 Cache can be used even in such scenarios where multiple application or web servers are put together into a farm.

The network access for such a distributed shared cache is optimized by using a asynchronous reliable multicast protocol. This is perfect for a cache cluster of unknown size.

Boosting Performance by using Fetch Plans - OpenAccess ORM provides for declarative coupling of Object Model and Activities through Fetch Plans.

FetchPlans describe object networks for performance optimizations. 

With the up-front declaration of a FetchPlan, OpenAccess is able to know in advance which object graph will be used by your code. This greatly improves your application performance in an easy and declarative manner.

This feature combines very well with the data fetches done by your application and avoids a common performance pitfall that is known as the ‘N+1 query problem’. Instead of querying for 1 order and then performing the n order details, a FetchPlan can be used to issue one optimal query fetching both order and its details. 

The FetchPlan is built up during runtime by a simple yet powerful API. The basic intention is to have a FetchPlan per use case. There is always a current FetchPlan, and this FetchPlan is used by queries and object navigation too. 

Philosophically, FetchPlans are the countermeasure to lazy-loading as they provide information for eager-loading.

Flexible Concurrency Mechanisms

OpenAccess supports both optimistic and pessimistic concurrency control. Both approaches can be mixed during runtime. Additionally it is possible to automatically obtain a pessimistic lock upon the first modifying access in an otherwise optimistic transaction.

When using optimistic concurrency control (the default), conflicts can be detected by designated version fields, the old content of the modified fields or all fields. And you can also turn conflict detection off.