Мы строим проект ASP.NET и инкапсулируем всю нашу бизнес-логику в классы обслуживания. Некоторые из них находятся в объектах домена, но обычно они довольно анемичны (из-за используемой нами ORM, которая не изменится). Чтобы лучше включить модульное тестирование, мы определяем интерфейсы для каждой службы и используем D.I.. например. вот пара интерфейсов:
IEmployeeService
IDepartmentService
IOrderService
...
Все методы этих служб - это в основном группы задач, а классы не содержат частных переменных-членов (кроме ссылок на зависимые службы). Прежде чем мы будем беспокоиться об Unit Testing, мы просто объявим все эти классы статическими и попросим их напрямую позвонить друг другу. Теперь мы настроим такой класс, если услуга зависит от других сервисов:
public EmployeeService : IEmployeeService
{
private readonly IOrderService _orderSvc;
private readonly IDepartmentService _deptSvc;
private readonly IEmployeeRepository _empRep;
public EmployeeService(IOrderService orderSvc
, IDepartmentService deptSvc
, IEmployeeRepository empRep)
{
_orderSvc = orderSvc;
_deptSvc = deptSvc;
_empRep = empRep;
}
//methods down here
}
Это действительно не проблема, но мне интересно, почему бы не создать класс factory, который мы передаем вместо этого?
то есть.
public ServiceFactory
{
virtual IEmployeeService GetEmployeeService();
virtual IDepartmentService GetDepartmentService();
virtual IOrderService GetOrderService();
}
Затем вместо вызова:
_orderSvc.CalcOrderTotal(orderId)
мы бы назвали
_svcFactory.GetOrderService.CalcOrderTotal(orderid)
Какое падение этого метода? Он все еще проверяется, он все же позволяет нам использовать D.I. (и обрабатывать внешние зависимости, такие как контексты базы данных и отправители электронной почты через D.I. внутри и вне factory), и устраняет много D.I. настройка и консолидация зависимостей больше.
Спасибо за ваши мысли!
