Question

Say you have an application divided into 3-tiers: GUI, business logic, and data access. In your business logic layer you have described your business objects: getters, setters, accessors, and so on… you get the idea. The interface to the business logic layer guarantees safe usage of the business logic, so all the methods and accessors you call will validate input.

This great when you first write the UI code, because you have a neatly defined interface that you can trust.

But here comes the tricky part, when you start writing the data access layer, the interface to the business logic does not accommodate your needs. You need to have more accessors and getters to set fields which are/used to be hidden. Now you are forced to erode the interface of your business logic; now it is possible set fields from the UI layer, which the UI layer has no business setting.

Because of the changes needed for the data access layer, the interface to the business logic has eroded to the point where it is possible to even set the business logic with invalid data. Thus, the interface does not guarantee safe usage anymore.

I hope I explained the problem clearly enough. How do you prevent interface eroding, maintain information hiding and encapsulation, and yet still accommodate different interface needs among different layers?

Answer 1

If I understand the question correctly, you’ve created a domain model and you would like to write an object-relational mapper to map between records in your database and your domain objects. However, you’re concerned about polluting your domain model with the ‘plumbing’ code that would be necessary to read and write to your object’s fields.

Taking a step back, you essentially have two choices of where to put your data mapping code – within the domain class itself or in an external mapping class. The first option is often called the Active Record pattern and has the advantage that each object knows how to persist itself and has sufficient access to its internal structure to allow it to perform the mapping without needing to expose non-business related fields.

E.g

public class User {     private string name;     private AccountStatus status;      private User()     {     }      public string Name     {         get { return name; }         set { name = value; }     }      public AccountStatus Status     {         get { return status; }     }      public void Activate()     {         status = AccountStatus.Active;     }      public void Suspend()     {         status = AccountStatus.Suspended;     }      public static User GetById(int id)     {         User fetchedUser = new User();          // Lots of database and error-checking code         // omitted for clarity         // ...          fetchedUser.name = (string) reader['Name'];         fetchedUser.status = (int)reader['statusCode'] == 0 ? AccountStatus.Suspended : AccountStatus.Active;          return fetchedUser;     }      public static void Save(User user)     {         // Code to save User's internal structure to database         // ...     } } 

In this example, we have an object that represents a User with a Name and an AccountStatus. We don’t want to allow the Status to be set directly, perhaps because we want to check that the change is a valid status transition, so we don’t have a setter. Fortunately, the mapping code in the GetById and Save static methods have full access to the object’s name and status fields.

The second option is to have a second class that is responsible for the mapping. This has the advantage of seperating out the different concerns of business logic and persistence which can allow your design to be more testable and flexible. The challenge with this method is how to expose the name and status fields to the external class. Some options are: 1. Use reflection (which has no qualms about digging deep into your object’s private parts) 2. Provide specially-named, public setters (e.g. prefix them with the word ‘Private’) and hope no one uses them accidentally 3. If your language suports it, make the setters internal but grant your data mapper module access. E.g. use the InternalsVisibleToAttribute in .NET 2.0 onwards or friend functions in C++

For more information, I’d recommend Martin Fowler’s classic book ‘Patterns of Enterprise Architecture’

However, as a word of warning, before going down the path of writing your own mappers I’d strongly recommend looking at using a 3rd-party object relational mapper (ORM) tool such as nHibernate or Microsoft’s Entity Framework. I’ve worked on four different projects where, for various reasons, we wrote our own mapper and it is very easy to waste a lot of time maintaining and extending the mapper instead of writing code that provides end user value. I’ve used nHibernate on one project so far and, although it has quite a steep learning curve initially, the investment you put in early on pays off considerably.