Entity Aggregation

Entity Aggregation is to group distributed redundant data from different repository across enterprise into one entity.

I translate the concept into a sample code just for the purpose of demonstration. Bear in mind that many more functionalities are required to sastify the actual definition of this pattern.

1. Repository1 and Repository2 classes are created just for showing the concept. In reality, data should come from database, xml, flat file and other storage mechanisms.
2. EntityAggregation class combines data from Repository1 and Repository2 into one unit for transporting across the wire in the real world.

using System;

namespace Test
{
  class Repository1
  {
    private string _fullname;
    public string FullName
    {
      get { return _fullname; }
      set { _fullname = value; }
    }
   
    private int _age;
    public int Age
    {
      get { return _age; }
      set { _age = value; }
    }
   
    public Repository1(string FullName, int Age)
    {
      this._fullname = FullName;
      this._age = Age;
    }
  }
 
  class Repository2
  {
    private string _fullname;
    public string FullName
    {
      get { return _fullname; }
      set { _fullname = value; }
    }

    private string _phone;
    public string Phone
    {
      get { return _phone; }
      set { _phone = value; }
    }
   
    public Repository2(string FullName, string Phone)
    {
      this._fullname = FullName;
      this._phone = Phone;
    }
  }
 
  public class EntityAggregation
  {
    private string _fullname;
    public string FullName
    {
      get { return _fullname; }
      set { _fullname = value; }
    }
   
    private int _age;
    public int Age
    {
      get { return _age; }
      set { _age = value; }
    }

    private string _phone;
    public string Phone
    {
      get { return _phone; }
      set { _phone = value; }
    }
   
    public EntityAggregation(string FullName, int Age, string Phone)
    {
      this._fullname = FullName;
      this._age = Age;
      this._phone = Phone;
    }
  }
 
  public class BusinessProcess
  {
    public EntityAggregation GetData()
    {
      Repository1 r1 = new Repository1("Mei Lin", 35);
      Repository2 r2 = new Repository2("Mei Lin", "1112223333");     
      return new EntityAggregation(r1.FullName, r1.Age, r2.Phone);
    }   
  } 
 
  public class Test
  {
    public static void Main(string[] args)
    {
      BusinessProcess bp = new BusinessProcess();
      EntityAggregation ea = bp.GetData();
      Console.WriteLine("FullName {0}  Age {1}  Phone {2}",
        ea.FullName, ea.Age, ea.Phone);
    } 
  }
}

Love to hear your ideas and do share your experience about this pattern.

Have fun 

Looks like a workaround for multi-inheritance? If the unique keys agree (in this case, FullName), then we create a new entity consisting of the various attributes associated to that unique key.

Is this the simplest design pattern to understand?

feelite wrote:

Looks like a workaround for multi-inheritance? If the unique keys agree (in this case, FullName), then we create a new entity consisting of the various attributes associated to that unique key. Is this the simplest design pattern to understand?

Yes, It look likes multiple heritance in many ways, but it's not. It only deal with gathering common data in one single entity dealing with multiple repositories spreading across the network. This is a workaround  of creating each entity mapping to each table reducing redundant data and code and more importantly transporting it across the wire in one trip instead of many trips. Yea, the FullName is just there to show the redundancy in data storage across different storage mechanism. It's not intended to be treated as the unique key, sorry for the confusion. In reality, the Repository1 and Repository2 classes should not be there and should be the SQL JOIN statement. At the end of the day, I think it looks more like a View to me.   

hmm, agree. On the DB level, it looks like de-normalisation that are usually performed during the physical db design stage, or like you say, it can be a view.

However, to appreciate the design pattern at the OO-level, i'm quite skeptical about it. Imagine what happens when the data in the underlying Repositories are changed but not reflected in the Aggregate. Another manager needs to be in place to update the data as soon as the underlying data is changed.

feelite wrote:

However, to appreciate the design pattern at the OO-level, i'm quite skeptical about it. Imagine what happens when the data in the underlying Repositories are changed but not reflected in the Aggregate. Another manager needs to be in place to update the data as soon as the underlying data is changed.

You're absolutely right about the change in data not reflected in the Aggregate. I was tempted to provide these functionalities when I was translating the pattern into OO code, but eventually backed out because it takes too much times and not my purpose here. We can always use the very well written Paladin provided by FireDancer without reinventing the wheel.