Лучшие практики для IoC в слое сложных сервисов [дубликаты]
На этот вопрос уже есть ответ:
Как избежать безумия конструктора Dependency Injection? 9 ответовЯ разрабатываю приложение MVC, я использую Unity для IoC. Мое приложение в основном состоит из уровня пользовательского интерфейса, уровня служб и уровня хранилища.
Мой типичный контроллер:
public class TestController : Controller
{
private ITestService testServ;
public TestController(ITestService _testServ)
{
testServ= _testServ;
}
public ActionResult Index()
{
testServ.DoSomething();
return View();
}
}
Ничего необычного, у каждого из моих контроллеров есть сервисный объект. Таким образом, объекты моего сервисного уровня выполняют сложные бизнес-правила, собирая информацию из множества разных репозиториев. Используя IoC, я обнаружил, что конструкторы выглядят слишком сложными, но поскольку службе требуется доступ ко многим репозиториям, я не вижу никакого способа обойти это.
Типичный класс в моем слое обслуживания будет выглядеть так:
public class TestService : ITestService
{
private ITransactionRepository transRepo;
private IAccountRepository accountRepo;
private ISystemsRepository sysRepo;
private IScheduleRepository schRepo;
private IProfileRepository profileRepo;
public TestService(ITransactionRepository _transRepo;
IAccountRepository _accountRepo;
ISystemsRepository _sysRepo;
IScheduleRepository _schRepo;
IProfileRepository _profileRepo)
{
transRepo = _transRepo;
accountRepo = _accountRepo;
sysRepo = _sysRepo;
schRepo = _schRepo;
profileRepo = _profileRepo;
}
public DoSomething()
{
//Implement Business Logix
}
}
Несколько объектов моего сервисного уровня требуют 10 или более репозиториев. Мой репозиторий использует Entity Framework, где каждый класс репозитория представляет таблицу в базовом хранилище данных.
Мне нужен совет по наилучшей практике в описанной ситуации.