Comments 24
Стоит отметить, что даже если вы не заводите под DataAccessLayer отдельную сборку, хранить репозиторий в Namespace Models не совсем верно. Модели — это DTOшки, любая логика должна храниться отдельно, за исключением, разве что, логики валидации этих моделей.
А зачем нужен такой PATCH, который по сути своей PUT? Честно сказать, зашёл только чтобы поглядеть, как PATCH реализовали.
Скриншот Google Chrome, что-то здесь не так.
Почему все последние примеры по ASP.NET core идут с IRepository? У нас же уже есть DbContext и DbSet?
Например:
И все.
Там где вы не хотите работать с физической базой данных (например в тестах) вы создаете контекст с dbContextOptions.UseInMemoryDatabase, а если в проде Postgres, то вот так:
Например:
public class ToDoContext:DbContext
{
public ToDoContext(DbContextOptions options):base(options){}
public DbSet<ToDoItem> Todos { get; set; }
}
И все.
Там где вы не хотите работать с физической базой данных (например в тестах) вы создаете контекст с dbContextOptions.UseInMemoryDatabase, а если в проде Postgres, то вот так:
services.AddDbContext< ToDoContext >(options => options.UseNpgsql(settings.Data.ConnectionString));
В целом — спасибо за статью и за комменты ).
Как то стало интереснее жить с .NET Core )
Как то стало интереснее жить с .NET Core )
Репозиторий неправильный, в нем не должно быть апдейта удаления и создания
А есть в ASP.Net Core что то вроде HTTP Module (из ASP.Net), что бы обрабатывать все запросы вручную и выкинуть весь тормозной хлам MVC?
Вроде бы да, можно еще посмотреть https://github.com/NancyFx/Nancy, тоже интересная штука)
Как уже тут написали — Middleware, достаточно подробно описано в официальной документации
Всё таки, было бы интересно прикрутить сюда и базу данных
Хочу выразить Вам, уважаемый автор, большую благодарность! Благодаря этой статье, въехал в суть Web Api Core! Спасибо большое!
Sign up to leave a comment.
ASP.NET Core: Создание первого веб-API с использованием ASP.NET Core MVC и Visual Studio