PhoneBook.Sample sub-project contains code for exercising the domain object classes without a GUI.
Program.cscontains most of the code discussed here
App.configcontains the important database connection info
PhoneNumberclasses 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 demo
QueryManProgram.csis used as sample code for this advanced document
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.