Class Naming Conventions with Layered Architecture and Entity Framework

Question

I'm designing a layered architecture (Service/Business Logic Layer, Data Access Layer) and am struggling with the intersection of a few problems.

• Entity Framework 4.1 does not support interfaces directly
• My Interfaces contain collections of other interfaces with read/write properties
  • This means using an implementing class won't work either, since it would still refers to another interface type

Example (please excuse the poorly written code, this is ad-hoc from my brain):

Data Access Layer

public interface IEmployer
{
    string Name { get; set; }
    ICollection<IEmployee> Employees { get; set; }
}

public interface IEmployee
{
    string Name { get; set; }
}

public class Employer : IEmployer
{
    public string Name { get; set; }
    public ICollection<IEmployee> Employees { get; set; }
}

public class Employee : IEmployee
{
    public string Name { get; set; }
}

public class DataManager
{
    public IEmployer GetEmployer(string name) { ... }
    public IEmployee CreateEmployeeObject(string name) { ... }

    public void Save(IEmployer employer) { ... }
    public void Save(IEmployee employee) { ... }
}

Service Layer

[DataContract]
public class Employee
{
    [DataMember]
    public string Name { get; set; }
}

public class HireService
{
    public void HireNewEmployee(Employee newEmployee, string employerName)
    {
        DataManager dm = new DataManager();
        IEmployer employer = dm.GetEmployer(employerName);
        IEmployee employee = dm.CreateEmployeeObject(newEmployee.Name);
        dm.Save(employee);

        employer.Employees.Add(employee);
        dm.Save(employer);
    }
}

Without EF, the above works fine. The IEmployee type is used in the service layer, and does not conflict with the Employee data contract type. However, EF cannot use an interface, so I would be required to use class instead of an interface.

I see a few options:

• Change IEmployer/IEmployee to classes, leaving the same names
• Change IEmployer/IEmployee to classes, rename to EmployerDAL/EmployeeDAL
• Change IEmployer/IEmployee to classes, rename to Employer/Employee, sprinkle using EmployerDL = DataLayer.Employer at the beginning of any service classes using it

What naming convention should I follow for class names which are defined in both the business and data layer?

Similar question to this: What's the naming convention for classes in the DataAccess Project? except that EF causes a problem with interfaces.

Answer 1

Actually the class defined in your DAL should be the one used in your business layer - those are your real domain objects. Classes exposed from your business layer are just data transfer objects so if you want to build any convention you should imho rename your data contracts.

Anyway the naming convention is something really subjective. Choose the way which best fits your needs and be consistent in that naming.