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

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

4 голосов
/ 08 ноября 2011

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

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

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

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

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

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

Ответы [ 3 ]

8 голосов
/ 08 ноября 2011

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

4 голосов
/ 08 ноября 2011

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

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

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

public class MyController : Controller
{
    private IPersonRepository personRepo;

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

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

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

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

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

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

1 голос
/ 08 ноября 2011

Некоторые подробности помогут.Возможно, немного кода?

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

Дополнительная информация здесь .

Редактировать 001:

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

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

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

...