ASP.NET Core и ViewModelFactory

Question

Здравствуйте, я пытаюсь реализовать шаблон «ViewModelFactory», и мне было интересно, что это лучший способ его достижения, учитывая ограничения текущего контейнера IoC.

public class UserCreateViewModelFactory 
{ 
    private readonly DbContext db; 

    public UserCreateViewModelFactory(DbContext db){ this.db = db;} 

    public void Create(CreateUserViewModel viewModel) 
    { 
      //Creates the user 
    } 
} 

У меня есть класс, который легко вводится в мои контроллеры ctor. Головная боль придет время, когда мне нужно больше ViewModelBuilders, поэтому я хочу, чтобы избежать двух вещей:

1. Bloat CTOR с инъекциями
2. Вздутие контейнер с регистрацией

Я хочу, чтобы иметь возможность вводить IViewModelFactory на мой контроллер и затем использовать его как это:

[HttpGet] 
public IActionResult GetUsers(int id) 
{ 
    return View(viewModelFactory.Build<GetUserViewModel>(id)); 
} 

Обратите внимание, что при вызове Build(T) он должен назвать правильный IViewModelFactory осуществления.

Я знаю, что поддержка контейнера StructureMap привязывает конкретные реализации к соответствующему интерфейсу, но я пытаюсь найти решение без необходимости добавления другой зависимости от проекта.

Answer 1

После некоторого исследования I наконец, придумал хорошее решение этой проблемы.

Решение в основном расширяет возможности IoC по умолчанию посредством метода расширения IServiceCollection.ConnectImplementations().

Во время регистрации я буду искать свои конкретные классы и подключать их с соответствующими интерфейсами (например, другими контейнерами). Затем я использую посредник/прокси, в который вводится IServiceCollection, и знает, какой конкретный класс должен строить модель представления.

Полное решение лучше объяснено this gist Я создал.

Answer 2

Я думаю, что если у вас есть строители для создания видовых моделей, то фабрика - это дополнительный слой абстракции, который просто можно отбросить.
Поскольку вы знаете тип созданной viewmodel во время компиляции, вы можете просто добавить создателя, который вам нужен для конструктора контроллера.

Если ваш контроллер создает множество режимов просмотра, и вы получаете множество строителей, которые вам нужно вводить - это можно рассматривать как признак нарушения принципа единой ответственности. В этом случае вам нужно отделить логику контроллера от разных контроллеров.

Так что я хочу, чтобы избежать два вещей:

Вздутия т е р с инъекциями

• Отдельный класс с раздутым конструктором других классов с более конкретной ответственностью, которая занимает меньшее количество зависимостей.
• или оберните зависимости с одним или двумя, тремя классами на основе их отношения

Вздутие контейнера с регистрацией

• Это не может быть проблемой, так как контейнеры зависимостей, как правило, предназначены для зарегистрировать весь «график объекта» вашей заявки