Schema-First Approach

Schema First Approach (Reverse Mapping) 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.

enlarge screenshot

See demo

Roundtrip Mapping

Roundtrip Mapping gives you the ability to dynamically change the direction: any change in the object model will change optionally your schema and any change in the database can optionally change your object model.

Model-First Approach

Model First Approach (Forward Mapping) 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.

enlarge screenshot

See demo

Dependent Instances

You can attribute a relationship so that the dependent instance is automatically deleted when no reference to it exists any longer.

Query Languages

With OpenAccess you got no limits, you can just use the best of all words, even combined.

LINQ

OpenAccess offers extensive LINQ support, which has been validated with the Microsoft 101 LINQ to SQL Samples. The major advantage of LINQ is the compile-time check of your queries – meaning no surprises later during runtime.

See online demo or download the OpenAccess LINQ 101 examples demo application

OQL

OpenAccess additionally supports 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.

See demo

Query Languages (cont.)

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.

enlarge screenshot

Runtime schema changes

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.

enlarge screenshot

See demo

Level 2 Distributed 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.

enlarge screenshot

See demo

Stored Procedures

enlarge screenshot

See demo

Concurency Mechanisms

enlarge screenshot

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. See demo
• 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.

enlarge screenshot

See demo

Support for Medium Trust Environments

Automatic Change Tracking

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.

Telerik Reporting

Asp.Net and MVC

SQL Azure

Silverlight and Ado.Net Data Services