Соглашения об именах классов с многоуровневой архитектурой и структурой сущностей - PullRequest
Новая
       36

Соглашения об именах классов с многоуровневой архитектурой и структурой сущностей

3 голосов
/ 25 апреля 2011

Я разрабатываю многоуровневую архитектуру (уровень логики обслуживания / бизнеса, уровень доступа к данным) и пытаюсь пересечь несколько проблем.

  • Entity Framework 4.1 не поддерживает интерфейсы напрямую
  • Мои интерфейсы содержат коллекции других интерфейсов со свойствами чтения / записи
    • Это означает, что использование реализующего класса также не будет работать, поскольку оно все равно будет ссылаться на другой тип интерфейса

Пример (пожалуйста, извините за плохо написанный код, это специально для меня):

Уровень доступа к данным 

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) { ... }
}

Сервисный уровень 

[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);
    }
}

Без EF выше работает нормально. Тип IEmployee используется на уровне сервиса и не конфликтует с типом контракта данных Employee. Однако EF не может использовать интерфейс, поэтому я должен был бы использовать класс вместо интерфейса.

Я вижу несколько вариантов:

  • Измените IEmployer / IEmployee на классы, оставив те же имена
  • Измените IEmployer / IEmployee на классы, переименуйте в EmployerDAL / EmployeeDAL
  • Измените IEmployer / IEmployee на классы, переименуйте в Employer / Employee, посыпьте, используя EmployerDL = DataLayer.Employer, в начале любого класса обслуживания, использующего его

Какое соглашение об именах следует соблюдать для имен классов, которые определены как на уровне бизнеса, так и на уровне данных?

Подобный вопрос: Какое соглашение об именах для классов в проекте DataAccess? за исключением того, что EF вызывает проблему с интерфейсами.

1 Ответ

1 голос
/ 25 апреля 2011

На самом деле класс, определенный в вашем DAL, должен быть тем, который используется на вашем бизнес-уровне - это ваши реальные доменные объекты.Классы, предоставляемые на вашем бизнес-уровне, являются просто объектами передачи данных, поэтому, если вы хотите создать какое-либо соглашение, вам следует переименовать ваши контракты с данными.

В любом случае соглашение об именах является чем-то действительно субъективным.Выберите способ, который наилучшим образом соответствует вашим потребностям, и будьте последовательны в названии.

...