Какая должна быть модель сущностей приложения?

Question

[Дмитрий]

Здравствуйте! Разбираюсь с архитектурой приложения и встал вопрос, какой должна быть модель сущностей приложения, имеется в виду какие сущности использовать чтобы записать данные в БД, это модель должна быть полной копией структуры БД, к примеру такой моделью которую Entity Framework генерирует

public class Player
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Position { get; set; }
    public int Age { get; set; }
 
    public int? TeamId { get; set; }
    public virtual Team Team { get; set; }
}
public class Team
{
    public int Id { get; set; }
    public string Name { get; set; } // название команды
    public string Coach { get; set; } // тренер
 
    public virtual ICollection<Player> Players { get; set; }
 
    public Team()
    {
        Players = new List<Player>();
    }
}

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

public class Team
{
 public int Id {get;set;}
 public int Price{get;set;}
}

а в таблице еще есть поля к примеру CreatedDate, ну и.т.д, вот вопрос правильнее будет сделать модель которая копирует БД включая связи, или же делать модель по типу Бизнес объектов? Я только разбираюсь в этом, поэтому расскажите как будет правильнее, критика, советы, ссылки на полезную литературу, все принимается

Answer 1

[unsafePtr]

Entity(сущность) должны представлять нашу таблицу в БД, и идеологически должна включать в себя все столбцы таблицы. Для взаимодействия с нашем слоем доступа к данным, используем DTO(data transfer object), именно здесь мы уже выбираем нужные нам свойства сущности, здесь же располагается наша бизнес-логика. Довольно часто такой DTO класс является полной копией Entity. К сожалению от этого ни как не избежать, если мы пытаемся сделать слои максимально независимыми между друг другом.
Добавлю ещё, что возможно вы сталкивались с паттерном Repository, так вот, не используйте его! Repository был придуман лет 20 назад, и туда обычно складывали SQL-заявки. В приложении в нём обычно нет смысла, так как ORM, в данном случае Entity Framework, берёт всю эту работу на себя, и все заявки мы пишем на LINQ. Repository имеет смысл, если мы собираемся писать SQL-заявки вручную, или же используем более одной БД.

Comments

[Дмитрий]

а что использовать вместо репозитория, в слое доступа к данным?

[unsafePtr]

Можно использовать Service паттерн. Это класс в котором содержится наша бизнес логика. Его конструктор принимает в качестве аргумента контекст(класс наследующий DbContext). Для удобства советую использовать Injector

[Дмитрий]

unsafePtr: т.е логику и работу с БД в один слой? А как же принцип единственной ответственности?

[unsafePtr]

Можете их разделить, но оба слоя будут зависимы от Entity Framework, что то же не есть хорошо. Можно к примеру создать dll куда мы сложим только сущьности, без EntityFramework, но тогда какой это уровень доступа к данным без ORM. Я поступаю следующим образом -создаю новый project который компилируется в dll, он внутри содержит папку Entities, сюда складываем все наши сущности, и папку Services, здесь у нас сами сервисы + DTO-объекты, ну и собственно EntityFramework. И уже из самого приложения в References указываем нашу скомпилированную либу, и пользуемся сервисами на здоровье.