PhoneBook.Sample -- learn what makes domain object classes tick

Owned by reinhard reinhard (Unlicensed)
Last updated: Jan 21, 2010Version comment

The PhoneBook.Sample sub-project contains code for exercising the domain object classes without a GUI.

  • Program.cs contains most of the code discussed here
  • App.config contains the important database connection info
  • Celebrities.cs instantiates Location, Person and PhoneNumber 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:

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.
See next