Не Внедряйте Сторонние Зависимости. Используйте Декораторы. Начало
Когда дело касается обычной сквозной функциональности вроде ведения журнала, отказоустойчивости или кэширования, лучшим решением обычно является применение паттерна Декоратор.
Часто можно видеть, как внедрение зависимости (DI) используется для внедрения, скажем, интерфейса журнала или классов пайплайнов Polly для отказоустойчивости в код приложения. Однако, лучшим решением было бы использование Декораторов.
Вот упрощённый пример:
public class MyApi
{
private ResiliencePipeline _pipeline;
private IService _svc;
public MyApi(
ResiliencePipelineProvider<string> prv,
IService service)
{
_pipeline = prv.GetPipeline("retry-pipeline");
_svc = service;
}
public List<string> GetSomething(
QueryByAttribute query)
{
var result =
_pipeline.Execute(() =>
svc.RetrieveMultiple(query));
return result.Entities
.Cast<string>().ToList();
}
}
Как протестировать такой класс? Да, в методе GetSomething всего пара строк, но это упрощённый код, можно предположить, что метод гораздо длиннее.
Класс MyApi связан с Polly, т.к. ResiliencePipeline определён в этой библиотеке. Связанность — главная причина спагетти-кода. Чтобы писать устойчивый код, вы должны осознавать степень связанности. Самый несвязанный код — это код, который вы можете легко удалить. Polly — прекрасная библиотека, и всё сказанное далее скорее относится ко всем сторонним зависимостям.
Также это не означает, что нельзя использовать высококачественные сторонние библиотеки, такие как Polly. Не стоит становиться жертвой синдрома «not invented here».
Когда дело доходит до классических сквозных проблем, паттерн Декоратор обычно предпочтительнее с точки зрения дизайна, чем внедрение проблемы в код приложения. Приведённый выше пример выглядит безобидным, но представьте, что вы внедряете ResiliencePipeline, логгер, возможно, сервис кэширования… И реальный код приложения в итоге тонет в «коде инфраструктуры».
Дело не в том, что мы не хотим иметь эти сторонние зависимости, а в том, что мы хотим переместить их в другое место.
Продолжение следует…
Источник: https://blog.ploeh.dk/2024/09/02/keeping-cross-cutting-concerns-out-of-application-code/