December 10, 2004

Learning about Object Orientation

Eric Evans proposes that the domain layer and persistance layer for an application should be seperated. It should be possible for the business coach to read the code in the domain layer. Whilst this appealled, I struggled to understand how this would be implemented.

Ade Oshineye has helped me to understand how this would work by writing the following example. The department object is persisted in the DepartmentRepository class. This keeps the department object clean of any persistence code. Thanks Ade.

public void testPersistedDepartmentCanBeRetrieved()
{
String name = "Sales";
Department sales = new Department(name);
Employee johnSmith = new Employee("John Smith");
sales.add(johnSmith);
Employee janeSmith = new Employee("Jane Smith");
sales.add(janeSmith);

DepartmentRepository repository = new DepartmentRepository();
repository.add(sales);

Department retrievedSalesDept = repository.findByName(name);
assertEquals(sales, retrievedSalesDept);

List employees = retrievedSalesDept.findAllEmployees();
assertEquals(2, employees.size());
assertTrue(employees.contains(johnSmith));
assertTrue(employees.contains(janeSmith));
}

public class DepartmentRepository {
public void add(Department dept) {
// insert into dept values(name)
// int id = dept.getId();
// List employees = dept.getEmployees();
// insert into emp values(name, did)
}

public Department findByName(String name) {
// select from emp where emp.name = name
}
}

Posted by chrismatts at December 10, 2004 3:36 PM
Comments

This pattern of a domain object and an associated Repository object is presumably the same as Fowler´s Mapper pattern, where the you have DepartmentMapper instead of DepartmentRepository? Anyway the last few lines of code where you assert that the list has both Jane and John Smith struck me a bit. The name you chose for the method that returns a list of Employee objects from the Department object, findAllEmployees, doesn´t sit right with me. Is this a method in the Department class that talks to a database? If not, and with Fowler´s Mapper pattern it would not, I´d probably name it simply employees. So one would have:

List employees = retrievedSalesDept.employees();

I think findAllEmployees implies a database, don´t you?

Posted by: Dadi at December 11, 2004 12:34 AM

Ok, I should have finished the entries in your blog since you or Ade changed this in the entry with the full source code to getAllEmployees. Sorry about that.

Posted by: Dadi at December 11, 2004 12:46 AM

You're quite right. The Repository classes should always use findBy* names to distinguish them from the get* names used by domain classes. In fact even the current version Chris posted has bugs to do with the department having a List of employees when it really ought to be a Set of employees since duplicates aren't permitted.

The Repository pattern described by Evans is different to Fowler's Mappers. The difference is mainly in the intent. Fowler's Mappers are a way of transforming objects into database records whilst Evans's Repositories are a way to separate out whatever persistence mechanism you've chosen from the domain model. A Repository implementation might use Mapper or any of the object-relational mapping patterns behind the scenes.

I hope to write more about this in my BookShelved review of DomainDrivenDesign.

Posted by: ade at December 11, 2004 2:49 PM
Post a comment









Remember personal info?