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
of DataObjects.Net Manual. That’s enough to start writing the applications on DataObjects.Net.
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.
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 Ohloh.net, that allows you to monitor the metrics related
to its development. Ohloh calculates them by monitoring and analyzing the changes made to source
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
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 method for previous version of DataObjects.Net is fully
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.