DataObjects.Net is the ideal ORM and business logic layer development framework for modern .NET projects. It will save you time and help you deliver a better product that is easier to maintain over time.

Visit DataObjects.Net website →

Automatic database schema upgrade

You no longer need to create and modify database schema manually. Just change the code of persistent classes in C#, and DataObjects.Net (integrated into your application) will change the database schema on the next application startup, preserving the data.

Support for legacy database schemas

DataObjects.Net automatically builds and maintains its own database schema as well as supports mapping to an already existing database without any modification of its structure.

Get rid of separated XML mapping files flooded with mainly duplicate information

Declarative mapping definitions based on attributes is primary way of describing mappings in DataObjects.Net.

Perfect LINQ support

DataObjects.Net integrates probably the most advanced LINQ to SQL translator. Currently it shows best result in LINQ quality test.

Built-in query optimizer

LINQ translation is a pretty complex problem.

Support of the most frequently used databases

A specialized provider for each database utilizing its unique features ensures DataObjects.NET delivers high performance on every database platform.

Integrated database

DataObjects.Net can operate without an external database at all. The database we integrated into it currently is capable of storing the data only in RAM, but even this turns it into a perfect solution in certain cases, e.g. it is especially good for unit testing. In near future it must become a full-featured database.

Transactional transparency

Transparent actualization of persistent object state on crossing isolation boundaries, declarative way of specifying transaction boundaries and automatic transaction reprocessing are essential components forming this feature.

High performance

DataObjects.NET designed to operate with large volumes of data under high load. It is the only ORM allowing the application to „crunch“ unlimited amounts of data even in a single transaction.

Full-text indexing and search Full-text indexing and search

Declarative full-text index management and Query.FreeText(...) method allowing to mix full-text and ordinary LINQ queries must be the perfect combination in terms of simplicity and supported features. In the future we’re planning to add support for Lucene.Net in addition to full-text search services integrated into RDBMS.

Localized versions of objects

An API based on special persistent types, that greatly simplifies implementation of localized versions of objects.

Right now we’re working on bringing to you:

Access Control System

Virtually any application working with database includes such a subsystem.

10 reasons to use DataObjects.Net



You’ll need 10 minutes to quickly review methods and properties of just 6 types: Domain, Session, Transaction, Entity, EntitySet<T> and Query to understand how to use DataObjects.Net. 10 more minutes are necessary to review properties of 5 attributes: [HierarchyRoot], [Field], [Key], [Association] and [Index]. Now you know how to affect on database schema creation and mapping. Finally, 20 more minutes are necessary to read first section of DataObjects.Net Manual. That’s enough to start writing the applications on DataObjects.Net.


Get help on

With the quite efficient Q&A support system, our specialists are available for your questions on any aspects of DataObjects.Net usage on 24x7 basis. Moreover, other DataObjects.Net users are favoured to assist you!



DataObjects.Net supports arbitrary key types, including composite keys, but offers unified API hiding all these differences. Entity.Key returns the key of the entity; Query.Single(key) resolves the key to entity. Any Key can be converted to a string and vice versa, compared to another one, converted to a sequence of its field values (Tuple), etc.

DataObjects.Net supports both custom object version definitions (two versions of the same entity differ if and only if they belong to its different states), as well as the default one, which includes values of all non-lazy fields of the entity into its version. Version information is always represented by VersionInfo instances; Entity.VersionInfo returns current version of an entity; different versions can be compared and serialized. So this API enables using unified optimistic locking everywhere.

Instead of providing a set of collections that really have no analogues in relational databases (collections like List<T> are implied here), DataObjects.Net offers the only collection type: EntitySet<T>. It describes both one-to-many and many-to-many relationships in most precise way.

DisconnectedState replaces different types of sessions (or entities) for connected and disconnected modes, changing the behavior of regular sessions. DisconnectedState.Attach „switches“ the session into disconnected mode, forcing it to serve the data cached in DisconnectedState first and thus making it very similar to the ADO.NET DataSet. DisconnectedState resolves the problems that are solved by a NHibernate.Burrow.

The cases described here are certainly not all the examples of unification, but they give certain impression of DataObjects.Net design principles.


Team openness

We have done all we could to ensure the commercial project has received all the advantages of open source and agile development:

  • Project source code repository, issue tracker and technical support forum are publicly available.
  • Continuous integration and unit testing of the project were established on the initial stages of its development. Now we have more than 2200 tests covering about 80% of its code. So we know with very high reliability, if/how the current version DataObjects.Net is stable.
  • The project is registered at, that allows you to monitor the metrics related to its development. Ohloh calculates them by monitoring and analyzing the changes made to source code repository.
  • Key project developers maintain blogs, which gives some insight on what is happening at the moment.
  • Developers’ contacts are publicly. You can easily contact any member of our team via Skype, e-mail or phone.
  • „Nightly builds“ provide an opportunity to receive the latest changes on the next day.


DataObjects.Net offers a single „starting point“ for all kinds of queries: Query type. Its methods (All, Single, SingleOrDefault, FreeText, Execute, ExecuteScalar, ExecuteFuture and ExecuteFutureScalar) allows to run regular, compiled and future (delayed) LINQ queries and perform instance fetches (resolve keys to entities).

The framework supports a concept of current session, but does not force you „switching“ it — our aspects for PostSharp make this transparently for you. When a method of an object associated with a Session (ISessionBound object) is invoked, these aspects ensure that current session in the current thread is the one to which object belongs, so they perform automatic activation and deactivation of session during the method execution. This means you shouldn’t care about passing the Session explicitly — e.g. there is no need to pass it to entity constructors; on the other hand, such an approach does not suffer from the issues related to transferring the objects associated with sessions to other threads.

There is no need to invoke Save, Attach and Refresh-like methods — registration of new entities, change tracking and flushing, as well as entity state refreshes are performed completely automatically, when this becomes necessary.

Entity and EntitySet<T> provide integrated implementation of IDataErrorInfo, INotifyPropertyChanged and INotifyCollectionChanged — so you can bind them to UI controls right out-of-the-box.

Convention over configuration is one of the most important design patterns in DataObjects.Net. It’s enough to register an assembly (.dll) in domain configuration to make all of its persistent types, services, LINQ compilers and preprocessors, modules and upgrade handlers available to DataObjects.Net; so a single registration action allows you to add new types to the assembly without caring about their actual injection further. In general, any configuration API in DataObjects.Net is designed to ensure that fine tuning is always possible, but is not mandatory.


Most frictionless environment you can find

DataObjects.Net helps you to model complex domains with ease, because it supports the development path you used to follow. We put a lot of efforts to allow you thinking of persistent objects as of regular .NET objects. DataObjects.Net relies on „Model-First“ (or „Code-First“) concept pushing developers to focus on domain model and its business logic instead of caring about how and when the entities must be persisted. This allows you to design models using just usual .NET classes. Moreover, we eliminated the need to maintain separate XML mapping files.

So building complex models containing hundreds of persistent types is nearly as simple as doing the same for non-persistent models.


High-quality technical support

Starting the communications with our team, you get contacts of real persons helping you to solve your specific problems further. At Xtensive, the typical „developer“ — „customer“ relationship is one-to-many rather than many-to-many. This means the whole background and history of communications with you are well-known to the person you are interacting with. Normally you know exactly who will answer your next question. Furthermore, you can always talk with any us personally using Skype, e-mail or phone.


ROI calculation

ROI calculation method for previous version of DataObjects.Net is fully described here. In short you may get the 40%-50% economy reducing both the cost and the time necessary to implement the requirements.

New version makes possible to get much more.


True storage independence

DataObjects.Net is, likely, the first ORM designed to compile LINQ queries not just to SQL, but to generally any other query language. Its internal query representation is similar to query plan used in SQL databases instead of AST. This feature allows it to perform really complex query transformations while producing query for target database. It is capable of doing the same jobs as query optimizers in regular databases do — in particular, it can produce efficient query plans for indexing engines. Currently DataObjects.Net supports:

  • Microsoft SQL Server 2005 / 2008
  • Microsoft SQL Server CE 3.5
  • SQL Azure Database (formerly SQL Data Services, SDS or SSDS)
  • Oracle 9i, 10g and 11g
  • PostgreSQL 8.2, 8.3, 8.4 (freeware, open source)
  • Integrated in-memory database (IMDB or IMDS) supporting all the framework features including indexes and LINQ queries
  • Built-in file system database (i.e. regular embedded database, upcoming)
  • MySQL (upcoming)

DataObjects.Net allows to transparently migrate between any of storages it supports.


Rapid framework development

Just 6 months are passed now since the official release of version 4.0 (almost a „naked“ platform), but during this short period DataObjects.Net got lots of features that aren’t available in any of its competitors. Moreover, most of features available in DataObjects.Net 1.X. .. 3.X are implemented in v4.X branch now. So during these 6 months we have passed almost the entire path of development of versions 1.X-3.X — earlier this took about 2 years!

We have implemented about 350 issues out of 500, that were logged during this period in the project’s issue tracker. This became possible partially because of much nicer architecture (we spent about a year on the platform itself) and partially (and may be, mainly) because of the experience we gained over the years of work on previous versions of our product.

If you compare DataObjects.Net with other ORM solution available today, you will come to a clear conclusion: the speed and dynamics of its development is definitely the highest one.