погромист
ConfigureAwait) уже обсуждались во многих статьях, поэтому я не буду подробно останавливаться на них. Цель заключается в том, чтобы сформировать компактный список моментов, на которые нужно обращать внимание, а не давать подробную техническую выкладку по каждому из них.
Меня зовут Алексей Казаков, я техлид команды Клиентских коммуникаций в ДомКлике. В этой статье я хочу поделиться с вами «рецептом», который позволил нам реализовать отложенные ретраи при использовании брокера сообщений RabbitMQ
Разработчик SimpleInjector очень любит «декораторы», особенно в сочетании с дженериками видаQueryHandler<TIn, TOut>, CommandHanler<TIn, TOut>.
public class MoveProductParam
{
public ProductId {get; set; }
public CategoryId {get; set; }
}
//...
if(!dbContext.Products.Any(x => x.Id == par.ProductId))
return BadRequest("Product not found");
if(!dbContext.Categories.Any(x => x.Id == par.CategoryId ))
return BadRequest("Category not found");
public class MoveProductParam
{
[EntityId(typeof(Product))]
public ProductId {get; set; }
[EntityId(typeof(Category))]
public CategoryId {get; set; }
}
Как пользователь я хочу изменить ФИО и email в системе.
string ExecuteUseCase()
{
var request = receiveRequest();
validateRequest(request);
canonicalizeEmail(request);
db.updateDbFromRequest(request);
smtpServer.sendEmail(request.Email);
return "Success";
}
let executeUseCase =
receiveRequest
>> validateRequest
>> canonicalizeEmail
>> updateDbFromRequest
>> sendEmail
>> returnMessage
int, пришел string – возвращаем 400your@mail.com, а пришло 123Petya – возвращаем 422К сожалению стандартный механизм байндинга ASP.NET MVC не различает ошибки несоответствия типа (получилиstringвместоint) и валидаци, поэтому если вы хотите различать 400 и 422 коды ответа, то придется это сделать самостоятельно. Но речь не об этом.
Вопрос ограничения доступа к данным встает при разработке многопользовательских систем почти всегда. Основные сценарии следующие:
