What objects should you return from the data access layer to the business layer an n-tier system

Question

If you have, for example, a database table called Person (ID,Name etc) what kind of object should the data access tier return to the business tier? I'm thinking something like this:

//data access tier
public class DataAccess{

   public interface IPerson{
      int ID{ get; set; }
      string Name{ get; set; }
   }

   internal class Person : IPerson{
      private int id;
      private string name;

      public int ID{ get{return id; } set{ id=value; } }
      public int Name{ get{retutn name; } set{ name=value; }
   }

   public static IPerson GetPerson(int personId)
   {
      //get person record from db, populate Person object
      return person;  
   }
}

//business tier
public class Person : IPerson{
   private int id;
   private string name;

   public int ID{ get{return id;} set{id=value;} }
   public string Name{ get{return name;} set{name=value;} }

   public void Populate(int personId){
      IPerson temp = DataAccess.GetPerson(personId);
      this.ID = temp.ID;
      this.Name = temp.Name;
   }
}

But this all seems a little cumbersome? Is there a more elegant solution to this problem? Should I return a DataRow from the data access layer to the business layer instead?

Answer 1

You don't need to repeat the class definition in your data access layer (DAL).

You can create your business entities as 'dumb' containers in a separate assembly, e.g. your Person class can just be:-

public class Person
{
    int ID { get; set: }
    string Name { get; set: }
}

Then, you can give your DAL a reference to the business entities layer. Your controller objects, whether they are in a separate business logic layer, or within your UI layer, can then just call the DAL, which can create a business entity, populate it from the database and return it to your controller.

This article by Imar Spaanjaars has a nice explanation of this pattern.

Answer 2

Your business layer definitely doesn't want to know about data rows - try to leave data specific classes in the data layer. This reduces coupling and frees you to change your persistence layer at a later date without wholesale re-architecting.

To solve your specific problem, you can either:

• Create basic data objects/entities in your data layer and hand them off to your business layer for consumption.
• Or, as it seems you are doing, create DTOs (Data Transfer Objects) that exist purely as a means of transferring data from the data layer to a richer implementation of your business object in a higher layer. You might do this as part of a repository pattern in a rich domain model.

The other thing you might want to think about is tiers v layers - it makes a difference how you think about these things. Tiers are generally physical, in other words they define the boundaries between processes. Layers are generally logical, they separate a program's functionality into loosely coupled units. You are aiming for layers in this case.