The PhoneBook.Sample sub-project contains code for
exercising the domain object classes without a GUI.
Program.cscontains most of the code discussed hereApp.configcontains the important database connection infoCelebrities.csinstantiatesLocation,PersonandPhoneNumber
classes to fill your database
Not discussed here is extra sample code, including the
copy of queries.xml, mentioned on the
PhoneBook.Domain -- learn to declare domain object classes page:
ProgramDeleteDemo.csis used for the log4net demoQueryManProgram.csis used as sample code for this
advanced document: http://re-motion.org/community/LinkClick.aspx?fileticket=o0EEx 8Z7T0=&tabid=70
Client transactions – the core of re-store
- Domain objects are held in memory only for as long as operations on
them are in progress. This is inevitable, because operations
require domain objects, domain objects require client transactions,
and client transaction have a limited life expectancy. As soon as
the client transaction is discarded, all traces of the domain
objects vanish with them.
- A client transaction is usually passed to a transaction scope, of which
the extent is clearly visible. It is always obvious which objects belong to
what client transaction and which transaction is active for a given scope.
- How much or how little a client transaction includes, after it has started
and before it ends, can be programmed along a unit of work, not data
constraints. The programmer has control over what constitutes a unit of work. - It is easy to build family trees of parent-/child-transactions to map the
behavior of a user whose actions fan out over a tree of loaded domain
object instances (or trees of form windows opened in the course of the
unit of work). - No matter how complex this data structure becomes, the risk of dangling,
forgotten client transactions is minimized.
...