Давай предположим, что авторизации нет. Она - это совсем другая история. Значит у нас остаются две сущности: сущность книги(к примеру) и категория книги
Модель книгиpublic class Book
{
public string Id { get;set; }
public string? Name { get; set; }
public string? Description { get; set; }
public int CategoryId { get; set; }
public Category? Category { get; set; }
}
Модель категории
public class Category
{
public string Id { get; set; }
public string? Name { get; set; }
public string? Description { get; set; }
}
В моделях можно заюзать рекорды, но это фишка новых версий и возможно у тебя её банально нет. Далее создаёшь контекст файл для базы данных (в случае ef core, даппер тебе на данном этапе не нужен). В контекст прописываешь сеты для моделей. Ничего дополнительного делать не надо, современный еф кор поймёт что надо сделать и при миграциях всё построит сам. Ты кнш можешь заюзать database first, но тогда этот вопрос далеко не по шарпам = неверная категория вопроса.
И если не париться над архитектурой то прямо в контроллере пишешь методы представлений с использованием в них же appdbcontext
Пример с добавлением сущности в бд
public IActionResult Index()
{
IEnumerable? list = _db.Categories.ToList();
return View(list);
}
public IActionResult Create()
{
return View();
}
[HttpPost]
public IActionResult Create(Category obj)
{
_db.Categories.Add(obj);
_db.SaveChanges();
return RedirectToAction("Index");
}
То есть для каждой операции по 2 экшена => 1 отдаёт представление, второй обрабатывает заполненную форму. Единственное, для delete 1 метод, там нечего обрабатывать, сразу удаляешь при нажатии на кнопку.
В index представлении циклом достаёшь все объекты в табличку, а в create post форма, которая отправит промежуточный объект в контроллер.
Так никто не пишет в реальном проекте, но для понимания думаю сойдёт. В лучшем случае тут должны быть по 2 сущности (domain and db entities) и слои из чистой архитектуры, но мне лень это делать да и тебе тогда будет скучно
