Whenever business objects are based on non-guid keys (see Creating Business Objects that Use non-Guid Primary Keys), the corresponding entities need to support those scenarios as well. Luckily, very little work is required to enable entities to work with integer or string keys. The main difference is that instead of supporting a constructor that takes a Guid, we need to support constructors that support integers and strings instead. This makes it possible to instantiate the entity objects and pass along the appropriate keys, so the objects can load themselves.

The first example shows the integer version:

public class EmployeeEntity : BusinessEntity 
{
   public EmployeeEntity() : base() {}
   public EmployeeEntity(int id) : base(id) {}
   // ... the rest of the class continues on as usual.

A string-based entity is created in a very similar fashion:

public class EmployeeEntity : BusinessEntity 
{
   public EmployeeEntity() : base() {}
   public EmployeeEntity(string id) : base(id) {}
   // ... the rest of the class continues on as usual.

Also, entities that are based on string or integer primary keys, we need to use different properties to query the keys. Here's the integer version:

int intKey = oEnt.PKInteger;

And the string version:

string strKey = oEnt.PKString;

Asides from these differences, simple entities behave exactly the same way, no matter what keys the are based on. Most of the differences are absorbed by the business object (see also: Creating a Simple Business Object).

However, there are additional considerations for entities that manage related child records. For more information, see Creating a Collection of Child Objects.