A Proposal for an Abstract Domain Pattern

In this blog entry I describe a proposed pattern that I will call Abstract Domain.   It’s not an actual pattern yet since I don’t know of any examples of someone using it.    The proposed pattern is related to the idea of programming to interfaces but instead of an interface we use abstract classes.   Here are some of the details.

1.  Create Abstract Domain and Abstract Repository Classes
The abstract domain classes and abstract repository classes form the “abstract core” of the domain.  We can use a naming convention of having an “A” prefix to indicate abstract and the “Set” suffix to indicate a repository.   So ACustomer is the abstract Customer class and ACustomerSet is the abstract customer repository.  

2. An Abstract Domain Class is mostly Identity and Behavior
An abstract domain class has little or no state and as much behavior as possible.   I envision that an abstract domain class might include identifying fields, various abstract properties, and various abstract and virtual methods.  It could define identity by overriding the object.Equals.  

3.  Abstract Repositories are General Purpose Sets
It encompasses the idea of in memory sets as well as database repositories.  One idea I want to explore is the possibility that when a database repository returns a collection of domain objects it might return an in memory repository instead of an array or list.  

4.  Proxies, Views and Snapshots Inherit from the Abstract Domain Class

  •  A proxy is an implementation of the abstract domain class that passes abstract properties and methods on to another abstract domain object for handling.  A proxy may be lazy loaded by having it load the related abstract domain object from a repository only when needed.
  • A view is a kind of lazy loaded proxy except that includes the state information for the fields in the view so it only need to load the full object when a field not in the view is referenced.
  • A snapshot is an implementation of the abstact domain class that throws an exception whenever a property setter or method that updates that the state of the object is executed.

5.  Domain Object State Can Implemented in Various of Ways

For example you could have two versions of a Customer class one which implements state as a set of private fields and one representing states as an internal ADO.Net data row.   The application should work the same regardless of which version you use.

Okay, enough with the theory already.  Lets see some example C# code!   Here’s a simple abstract domain object.

public abstract class APerson
{      
    // we define identity in the abstract class
       protected int _personID;
       public int PersonID {get {return _personID;}}
       public override Equals(object obj)
       {    
              if (obj == null) {return false;}
              APerson person = obj as APerson;
              if (person == null) {return false;}
              return _personID.Equals(person.PersonID);
        }
       // we define abstract properties and methods
       public abstract string Name{get;set;}
       // references to other domain classes use the abstract class
       public abstract APerson Father{get;set;}
       // one to many relationships use the abstract set
       public abstract APersonSet Children{get;}
       // some behavior can be defined in abstract class
       public bool NameIsUnknown()
            { return (Name == null || Name == “”)}
}

Here’s the beginning of an abstract repository.  Its going to need more behavior than this but this blog entry is getting pretty long so that will have to be the subject of another blog entry.

public abstract class APersonSet
{
       public abstract APerson GetByID(int personID);
       public abstract bool Contains(APerson person);
       public abstract void Add(APerson person);
       public abstract void Save(APerson person);
       public abstract APersonSet Find(string criteria);  
}

Here’s a concrete domain class with an example of lazy loading.

public class Person : APerson
{
     // store state as private fields
      private string _name;
      private APerson _father;
      private APersonSet _children;
      // Lets store the repository that the person came from
      // so I can do lazy loading.  
      private APersonSet _repository;
      // for now just a simple constructor
      public Person(int personID, APersonSet repository)
      {
           _personID = personID;  // defined in base class
           _repository = repository;
      }
      // override abstract methods
      public override string Name
           {get{return _name}; set{_name = value;}}
      public override APerson Father
           {get{return _father}; set{_father = value;}}
      // we decide to lazy load the children
      public override APersonSet Children
      {
           get
           {
                 if (_children == null)
                 {
                      _children = _repository.Find(“x where x.Father = this or x.Mother = this”);
                      return _children;
                 }
           }
}

Here’s a PersonView class would be useful for picklists showing just the person name.

public class PersonView : APerson
{
    private string _name;
    private APerson _person;
    private APersonSet _repository;
    public PersonView(int personID, string name, APersonSet repository)
   { 
        _personID = personID;  // defined in base class
        _name = name;
        _repository;
    }
    public override string Name
    {
         get
         {
                if (_person == null) {return _name;}
                else {return _person.Name}
          }
          set
          {
               if (_person == null) {_name = value;}
              else {person.Name = value}
          }
    }
    public override APerson Father
    {
         get
         {
               if (_person == null) {_person = _repository.GetPerson(_id);}
               return _person.Father;
          }
          set
          {
               if(_person == null) {_person = _repository.GetPerson(_id);}
               _person.Father = value;
          }
    }
    // implementation of the Children property is similar to above so I won’t show it here.
}    

About these ads

3 Responses to “A Proposal for an Abstract Domain Pattern”

  1. Repositories in the Abstract Domain Pattern « Bill Hamaker’s Blog Says:

    [...] Bill Hamaker’s Blog Just another WordPress.com weblog « A Proposal for an Abstract Domain Pattern [...]

  2. webdesign Says:

    Discovered regarding that site from my friend. He aimed me here and advised me I’d find what I need. He was appropriate! I got all the inquiries I had, answered. Didn’t also consider extended to uncover it. Love the truth that you made it so easy for people enjoy me. Much more power

  3. Domain-Driven Design Resources « Angel “Java” Lopez on Blog Says:

    [...] A Proposal for an Abstract Domain Pattern « Bill Hamaker’s Blog http://billhamaker.wordpress.com/2006/08/24/a-proposal-for-an-abstract-domain-pattern/ [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: