re-store persists domain =
objects

=20

re-store is re-motion's O/R-mapper, but also responsible for transaction=
s. re-store persists domain objects in an arbitrary database, but =
at the time of this writing, only Microsoft SQL 2005/2008 is supported. Wri=
ting an adapter for other databases is an advanced programme, but thanks to=
good Linq-integration ("re-linq") a=
nd well thought-out interfaces a straightforward affair of software enginee=
ring. Such integration is not limited to relational databases, by the way. =
Object-oriented databases or XML-stores are also welcome with re-store.

At the time of this writing, re-store does not support class table inher=
itance. The good news is that you can build good O/R-mapping from a combina=
tion of single and concrete table inheritance. (Fairly embellished plans ex=
ist, but don't hold your breath.) For learning how to control single and co=
ncrete table inheritance, read the corresponding section of the PhoneBook walk-through, the The DBTable attribut=
e (Location class).

=20

re-store can do its work - mapping from properties in .NET classes to co=
lumns in tables - after a corresponding schema has been derived by program =
generation. This is done by a command-line tool named dbschema.exe.

=20

re-store does lazy loading

=
=20

Persisting objects is not worth anything without re-loading persisted ob=
jects when they are needed. re-store supports "l=
azy loading", i.e. only domain objects needed for a given operation of =
the user are actually loaded into memory. Domain objects are loaded in thei=
r entirety. If a domain object references other domain objects it is typica=
l that all referenced domain objects get also loaded, because their display=
name is stored in them and is needed for completely displaying the referen=
cing domain object. Since re-store does not load single properties, all tho=
se reference domain objects are loaded.

=20

re-store manages =
client transactions

=20

re-store provides a powerful transaction system. A client trans=
action, as re-store transactions are called, can spawn sub-transactions and=
limit them to their own transaction scope. You can build arbitrar=
ily complex trees of transactions and sub-transactions. A commit i=
n a sub-transaction writes modifications back into the parent tran=
saction that spawned the sub-transaction. In this fashion, modifications bu=
bble up from sub-transaction to the root transaction. As soon as t=
he root transaction is committed, re-store actually writes the accumulated =
modifications into the database. This is important for typical re-motion ap=
plications where users can open child forms from parent forms by following =
a reference property to a referenced domain object with its own form. If th=
e user decides to discard modifications at any one point in the tree of tra=
nsactions/opened windows, then the modifications of all children are forgot=
ten and don't make it into the database. The ultimate example is pressing t=
he Cancel button in a form that spawned a bushy tree of child form=
s/transactions, because this window corresponds to the root transa=
ction. Canceling the form means discarding all modifications that have accu=
mulated in that root transaction.

=20

Transaction scopes are a programming mechanism for keeping trac=
k of where in the tree of transactions execution of the program is located.=
Transaction scopes keep variables containing (sub-)transaction objects loc=
al to the parent transaction and give the programmer a natural sense on whi=
ch part of the code belongs to which transaction.