Аргументы интерфейса в ASP.NET MVC - PullRequest
3 голосов
/ 06 июля 2010

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

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

Совершенно логично, что когда мой контроллер создается фабрикой контроллеров, зависимости должны передаваться в мой конструктор как интерфейсы, но как быть с объектами данных, созданными связывателем модели?Должны ли они быть также зарегистрированы в моем контейнере IoC?

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

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

TIA, -J

1 Ответ

2 голосов
/ 07 июля 2010

Ни за что. Вы не решите проблему, для решения которой предназначен IoC.

Viewmodels должны быть немыми, как грязь. IoC хорош для обмена деталями реализации. Поскольку ваши модели представления глупы, какие детали реализации вы можете поменять местами? Модели представлений также имеют узкие и неортогональные обязанности, очень отличающиеся от традиционных инъекционных классов, таких как ILogger или IRepository.

ИМХО, это будет серьезное чрезмерное проектирование, и в результате сложность (я предполагаю, что ответственность за расположение сервисов в ваших контроллерах для сценариев редактирования) не будет стоить.

...