Abstracting from the Physical Layer

In Figure A-3, we can see a short conceptual definition (illustrated with a Visual Studio 2005 class diagram) of some of our entities, which can be convenient if we decide to provide a conceptual definition of our application domain.

Figure A-3: The Visual Studio 2005 class diagram of our order system from a conceptual point of view

In Listing A-3, you can see a C# representation of this conceptual description.

Listing A-3: A sample object-oriented definition of our conceptual entities

  namespace NorthwindModel {     public partial class NorthwindEntities {         public List<Customer> Customers {             // ...        }         public List<Order> Orders {             // ...        }     }     public partial class Customer {         public string CustomerID {             get { return this._CustomerID; }             set { this._CustomerID = value; }         }         private string _CustomerID = string.Empty;         public string CompanyName {             get { return this._CompanyName; }             set { this._CompanyName = value; }         }         private string _CompanyName = string.Empty;         public string ContactName {             get { return this._ContactName; }             set { this._ContactName = value; }         }         private string _ContactName;         public string Country {             get { return this._Country; }             set { this._Country = value; }         }         private string _Country;         public List<Order> Orders         {             get {                 // ...             }         }     }     public partial class Order {         public int OrderID {             get { return this._OrderID; }             set { this._OrderID = value; }         }         private int _OrderID;         public DateTime? OrderDate {             get { return this._OrderDate; }             set { this._OrderDate = value; }         }         private DateTime? _OrderDate;         public DateTime? RequiredDate {             get { return this._RequiredDate; }             set { this._RequiredDate = value; }         }         private DateTime? _RequiredDate;         public DateTime? ShippedDate {             get { return this._ShippedDate; }             set { this._ShippedDate = value; }         }         private DateTime? _ShippedDate;         public Customer Customer {             get {                 // ...            }             set {                 // ...             }         }     } } 

The real problem is to load and manage entities like the ones we have just defined (which involves reading their contents from a database) in a way that is independent from the nature and structure of the database itself. Using standard programming languages, we have to define, write, test, and maintain a lot of plumbing to achieve this goal.

We also have to deal with several issues. For instance, whenever we load a parent entity (such as a Customer), is it best to also load its children (Orders for Customer instances, Order Details for Orders)? Or is it better to load children only when we really need to access them? The answer is probably, “It depends.” This is because when we access a Customer, we do not automatically also want her Orders. On the other hand, many times when accessing one Order we also need to enumerate its Details. Every time we need a Customer, is it better to execute a single query and load it from the database, or is it easier and faster to reuse an in-memory instance of that particular Customer? If we reuse object instances, do we need to worry about concurrency issues? We could go on for hours with questions like these. Unfortunately, there are not absolute solutions for every problem and application. There are just a few patterns and rules that suggest the most common and reasonable solutions. The best solution might be a data access technique that allows us to decide on a case-by-case basis.