Eko Santoso

See also: Other Geeks@INDC

Domain Model VS Data Mapper

Kalau di Data Mapper Kita menggunakan sebuah class bantu untuk melakukan operasi - operasi dari class modelnya, misalnya ada 2 buah class , yang pertama class Customer yang cuma berisi property dari Customer dan yang kedua Class CustomerMapper yang berisi methode operasi untuk class Customer. Berbeda dengan Domain Model , dimana sebuah objek memiliki property dan behavior yang jelas seperti ilustrasi dibawah ini:

1 . Domain Model

public class Customer {
   // properties
   public string FirstName;
   public string LastName;

   // methods
   public bool Save();
   public bool Delete();
   public Customer Get(int id);
   public CustomerCollection Find(Query aQuery);
}

 

1 . Data Mapper

public class Customer {
   // properties
   public string FirstName;
   public string LastName;
} // Note: no behavior

public class CustomerManager {
   public bool SaveCustomer(Customer aCustomer);
   public bool DeleteCustomer(Customer aCustomer);
   public Customer GetCustomer(int customerID);
   public CustomerCollection Find(Query aQuery);
}

Why don't try like this :

3. Fix It

public class Customer {
   // properties
   public string FirstName;
   public string LastName;
  
   public bool Save();
   public bool Delete();
   public Customer Get(int id);
   public CustomerCollection Find(Query aQuery);
}

public class CustomerManager {
   public bool SaveCustomer(Customer aCustomer) {
   
      aCustomer.Save();
       }
   public bool DeleteCustomer(Customer aCustomer) {
      
      aCustomer.Delete();
       }
   public Customer GetCustomer(int customerID) { // etc. }
   public CustomerCollection Find(Query aQuery) { // etc.}
}

So, si Objek Customer gak anemic, ada behaviournya, dan implementasi behaviournya dilakukan oleh CustomerMaanager, jadi gak melanggar kaedah OOP, Object CustomerManager bertindak sebagai facade service si objek Customer , baca POEA nya Martin Fowler.

Share this post: | | | |

Comments

Jimmy Chandra said:

Frankly, I don't quite see the benefit of what is being suggested here.  Especially when your main argument is to just make the domain object look a little less "anemic".  What is the real benefit?

However, it's different if your CustomerManager is talking to a base / interface. That will certainly satisfy the need of doing something like this. since the actual implementation of an abstract Customer base class / interface will change between call.  This will allow flexibility in your design.  Just in case you have domains such as InternationalCustomer, DomesticCustomer, etc. which might be saved to a different table, or different validation rules, etc.

Or if your CustomerManager is really a facade class that is doing more than just passing a single method call to the Domain object method. In this case, it is really a facade that will shield your API users from the inner working complexity of your Domain classes. ie. CustomerManager.DeleteCustomerOlderThan(DateTime date) which will might call Customer.Find method and iterate through it and do some checking and finally call Customer.Delete on each matching Customer object.

Don't hate the skinny object just because it's skinny, hehehe.  Skinny object has its purpose too. Hehehe.

# November 21, 2007 2:14 PM

ES said:

My suggest is to combine between Data Manager and Domain model, so We don't have to break the principle of OOP, object have state and behaviour.

# November 22, 2007 4:48 PM