Внедрение зависимостей для моделей

Я уверен, что кто-то спрашивал это раньше, но я изо всех сил пытаюсь найти где.

Я использую Ninject для удаления зависимостей из моих контроллеров вместе с шаблоном проектирования хранилища.

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

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

Что я могу сделать с привязкой пользовательской модели?

Немного предыстории: я опытный разработчик ASP.net, но новичок в MVC.

Источник

3 ответа

Решение

Основным преимуществом использования инфраструктуры внедрения зависимостей является IoC (Inversion of Control):

  • слабая связь
  • больше гибкости
  • проще тестирование

Так что обычно делают, чтобы внедрить репозитории через их интерфейсы, такие как

public class MyController : Controller
{
    private IPersonRepository personRepo;

    public MyController(IPersonRepository personRepo)
    { 
        this.personRepo = personRepo;
    }
    ...
}

Во время тестирования это позволяет легко вставить мой фиктивный репозиторий, который возвращает именно те значения, которые я хочу протестировать.

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

Просто подумайте с точки зрения тестируемости вашего контроллера: "Что бы я хотел сделать, чтобы протестировать его?"

  • Доступ к БД -> хранилище
  • Внешние зависимости -> другие классы BL, вызовы WS и т. Д.

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

Источник

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

Источник

Еще некоторые детали помогут. Возможно, немного кода?

Для начала вам следует избегать внедрения зависимостей в доменные объекты, а использовать доменные службы.

Еще немного информации здесь.

Изменить 001:

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

Наконец, у вас есть уровень представления с вашими представлениями и контроллерами. Контроллеры общаются с вами на уровне службы приложений. Таким образом, Контроллер продукта общается со службой каталогов (например, GetProductBySku). В Catalogue Service один или несколько репозиториев будут внедрены в его конструктор (IProductRepository, ICategoryRepository и т. Д.). В asp.net mvc довольно часто встречаются ViewModels. Поместите ViewModels в свой уровень обслуживания приложений.

Поэтому я не уверен, что вы имеете в виду, когда говорите "модели" и "предметные области", но я надеюсь, что это прояснит терминологию.

Источник
Другие вопросы по тегам