Организация данных модели EF Core отдельно от данных бизнес-модели
Как лучше всего хранить модель EF Core отдельно от бизнес-логики, которая естественным образом входит в модель?
Например, у меня есть Area, в котором есть некоторые точки данных, которые должны сохраняться (имя, идентификатор), а некоторые являются временными (игроки, предметы, возможно, эффект заклинания на области, например огненный шторм, который не следует сохранять в базе данных). ? Хочу ли я отдельную модель?
class AreaRecord {
public int ID { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}
class Area {
public AreaRecord AreaRecord { get; set; }
public ICollection<Player> Players { get; } = new List<Player>();
public ICollection<Effect> Effects { get; } = new List<Effect>();
public string GetExample() { return AreaRecord.Name + " has " + Players.Count; }
}
Не обращайте внимания на бесполезность GetExample(), я хочу сказать, что класс Area будет иметь бизнес-логику и временные данные. Например, я не хочу сохранять список Players, потому что, если игра перезапустится, в этой области не должно быть игроков.
Это умножается на множество (ItemRecord/Item, PlayerRecord/Player, AreaRecord/Area, RoomRecord/Room) и так далее. Это правильный подход? Какие ключевые слова или темы мне следует прочитать, чтобы понять, правильный ли это подход или найти лучший подход?
Мне кажется, я на данный момент понимаю, что модели EF Core не должны иметь бизнес-логику из-за ограничений, при которых у вас не может быть общедоступных установщиков для данных, которые не должны сохраняться. И я беспокоюсь о случайном добавлении нового столбца базы данных, если я использую Area в качестве модели бизнес-логики.
Я думаю, что часть моей проблемы заключается в поиске правильной терминологии, чтобы даже исследовать или задать свой вопрос.
Я рекомендую использовать контракты для ваших DTO. Вы можете найти образец в этом репозитории: github.com/kyree-henry/HealthInsurePro. Кроме того, рассмотрите возможность использования пакета AutoMapper и его метода расширения ProjectTo. Не стесняйтесь исследовать репозиторий и выбирать то, что вам нужно, если таковое имеется.
Ответы 1
Редактировать:
Я еще немного прочитал и нашел это. Я бы согласился с тем, что он говорит: статья
Я бы посмотрел здесь. Вы можете специально исключить свойства своих моделей.
Включенные и исключенные свойства
По соглашению в модель будут включены все общедоступные свойства с геттерами и сеттерами.
Определенные свойства могут быть исключены следующим образом:
public class Blog
{
public int BlogId { get; set; }
public string Url { get; set; }
[NotMapped]
public DateTime LoadedFromDatabase { get; set; }
}
Или вы можете сделать это в конструкторе моделей:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Blog>()
.Ignore(b => b.LoadedFromDatabase);
}
Спасибо за новости, Дэвид. Я думаю, что это соответствует тому, что я искал. Особенно: «Во-первых, ваша логика персистентности и логика бизнеса/домена должны быть разделены уровнями. Поскольку объект EF принадлежит уровню персистентности, а проверка (или общие операции) принадлежат уровню бизнеса/домена, они логически не должны найти себя в одном определении класса».
Если AreaRecord — ваша модель сущности, просто создайте из нее объект DTO и включите свойства/аксессоры, которые вам не нужны, в вашу модель сущности. Если вашим средствам доступа потребуется инъекция, я бы переосмыслил вашу стратегию. Постарайтесь сделать его простым и зависящим только от внутренних свойств.