Видео. Управление зависимостями в коде

7 апреля 2010 г.

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

Основные темы:

Перед этим видео желательно посмотреть пример разработки приложения с помощью TDD.


Исходники проекта
・ ・ ・

35 комментариев:

  1. SpeCT7 апреля 2010 г. в 18:37

    Спасибо большое. Очень рад, что подписался на Ваш блог :)

    Хочу поинтересоваться, как и где вы собираете сложные ViewModel для страниц и контролов в asp.net mvc. Я имею в виду ситуации, когда для сборки ViewModel оптимальнее использовать join (SQL/Linq), вместо нескольких запросов к репозитарию из слоя бизнес логики.

    Ещё раз спасибо за такую наглядную статью.

    ОтветитьУдалить
  2. Alexander Byndyu7 апреля 2010 г. в 23:11

    @SpeCT
    Привет!

    Тут нет универсального решения. Данные в модель собираются в контроллере, сами данные формируются в сервисе.

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

    ОтветитьУдалить
  3. Анонимный7 апреля 2010 г. в 23:16

    Несколько несущественных замечаний.
    1. Где-то на 12-ой минуте слово "хрупкость" употреблено не по делу. Правильнее было сказать "жесткость".

    2. Русское произношение некоторых слов (нулл вместо налл, продУкт, вместо прОдакт, репозИтори, вместо репОзитори и т.п.) несколько корежит слух. :)

    3. 24 минута. Сервис-локатор конечно же тоже можно доточить до состояния, в котором он будет управлять временем жизни создаваемых сервисов так, как вам надо. Фактически IoC-контейнер — это тоже сервис-локатор, только не статический.

    ОтветитьУдалить
  4. VoimiX8 апреля 2010 г. в 02:06

    не могли бы выложить исходники?

    ОтветитьУдалить
  5. Alexander Steshenko8 апреля 2010 г. в 07:52

    Супер, спасибо.

    ОтветитьУдалить
  6. hazzik8 апреля 2010 г. в 09:29

    @xoposhiy
    дело не в произношении, а в сути.

    ОтветитьУдалить
  7. Анонимный8 апреля 2010 г. в 12:59

    Хорошо что хоть еще кто-то в рунете что-то делает по дот-нету, а то я уж думал что смерть пришла :)

    ОтветитьУдалить
  8. build_your_web8 апреля 2010 г. в 14:25

    довольно интересно.

    ОтветитьУдалить
  9. Михаил Петров8 апреля 2010 г. в 14:46

    Спасибо, доклад очень понравился! Всегда удовольствием читаю (и слушаю) твой блог, Александр

    ОтветитьУдалить
  10. Михаил Петров8 апреля 2010 г. в 15:31

    Вопрос - зачем в примере нужен слой сервисов? Почему бы контроллеру не обращаться сразу к репозиторию?

    ОтветитьУдалить
  11. Alexander Byndyu8 апреля 2010 г. в 15:38

    @Михаил Петров
    Вы не поверите, этот вопрос стал самым популярным =)

    Дело репозитория - выборка данных. Дело сервиса - подготовка данных под конкретную бизнес-задачу.

    Функция GetLastProduct может использоваться не только ProductService и не только в функции FindLastCreatedProduct. Таким образом мы разделяем ответственность и избавляемся от дублирования.

    ОтветитьУдалить
  12. Михаил Петров8 апреля 2010 г. в 15:48

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

    ОтветитьУдалить
  13. Alexander Byndyu8 апреля 2010 г. в 15:49

    @Михаил Петров
    Точно.

    ОтветитьУдалить
  14. Unknown8 апреля 2010 г. в 17:30

    Добрый день.
    Можно получить исходники примеров на различных этапах демонстрации?

    PS: Какая версия ReSharper'a установлена в данном видео-примере?

    ОтветитьУдалить
  15. Alexander Steshenko8 апреля 2010 г. в 22:26

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

    Репозиторий отвечает за выборку данных. Только за выборку.(?) За persistence объектов бизнес логики отвечает другой компонент/подход/паттерн. Вопрос - какой и как?

    Второй вопрос. Репозиторий в конкретном этом примере имеет паблик метод getLastProduct, то есть это по сути метод реализующий бизнес требование, сервис нуждается в последнем продукте и мы в репозитории реализуем метод который нам это делает.
    Так как эти бизнес требования могут постоянно меняться плюс, например, этот репозиторий может использоваться из других сервисов - может потребоваться расширифть функциональность репозитория. Например может потребоваться там getLast10ProductsBeforeSomeSpecificDate.
    Каковы были бы ваши действия? Расширение / декорирование репозитория? Модификация интерфейса?..
    Введете работу с какими-то объектами запросов или дополнительную параметризацию методов репозитория прямо из сервисного слоя?

    Спасибо!

    ОтветитьУдалить
  16. Alexander Byndyu8 апреля 2010 г. в 22:56

    @s-stude
    Исходники выложил, но только заключительные.

    ReSharper 5 beta

    ОтветитьУдалить
  17. Alexander Byndyu9 апреля 2010 г. в 09:05

    @lcf

    > Репозиторий отвечает за выборку данных. Только за выборку.(?) За persistence объектов бизнес логики отвечает другой компонент/подход/паттерн. Вопрос - какой и как?

    Он отвечает за выборку и CRUD. Мы используем NHibernate, поэтому наши репозитории являются обертками над этой ORM.

    > Каковы были бы ваши действия? Расширение / декорирование репозитория? Модификация интерфейса?
    Здесь нельзя сказать наверняка, потому что нет универсальных решений, все зависит от специфики проекта.

    В каком-то случае будет удобно переделать функцию на GetLastProducts(int productCount) и все.

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

    ОтветитьУдалить
  18. Михаил Петров14 апреля 2010 г. в 22:11

    В своем видео ты говоришь о том, что мы избавились от зависимости например между слоем логики и слоем доступа к данным. А как же сам класс Product? От нем же знают все слои приложения? То есть если он входит в слой логики, то получается все слои зависят от слоя логики. Как с этим быть? :)

    ОтветитьУдалить
  19. Alexander Byndyu14 апреля 2010 г. в 23:06

    @Михаил Петров
    Класс Product входит в домен приложения, а о нем по-умолчанию знает весь проект. Это нормально.

    ОтветитьУдалить
  20. Михаил Петров14 апреля 2010 г. в 23:13

    Спасибо за оперативный ответ! В принципе, так и думал, но на всякий случай решил уточнить :)

    ОтветитьУдалить
  21. sombre hombre17 апреля 2010 г. в 19:59

    Активная инъекция зависимостей очень гармонично вписывается в инфраструктуру ASP.NET MVC, в которой есть такое единое место -- фабрика контроллеров -- в котором инъекция и производится. А как быть в классическом ASP.NET?

    ОтветитьУдалить
  22. Alexander Byndyu17 апреля 2010 г. в 23:41

    @sombre hombre
    Там тоже все нормально. Сейчас как раз готовлю статью об этом. Если коротко, то надо использовать шаблон шаблон MVP, более скоро будет =)

    ОтветитьУдалить
  23. dRn25 апреля 2010 г. в 22:17

    Заметил, что в примере вы регистрируете контроллеры (IController) в WindsorContainer`е без указания LifeStyle, т.е. по умолчанию их поведение будет определено как Singleton. Я правильно понимаю, что надежнее указать LifeStyle.Transient?

    ОтветитьУдалить
  24. Alexander Byndyu26 апреля 2010 г. в 00:03

    @dRn
    Спасибо, что обратили внимание. Код инициализации IoC-контейнера был скорее для демонстрации возможностей.

    ОтветитьУдалить
  25. zerkms27 апреля 2010 г. в 04:25

    Привет

    Не совсем понятно, зачем интерфейс IDataContext выносить наружу DomainModel.MyOrmImplementation.

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

    НО: взаимоотношения конкретной реализации репозитория (ProductRepository) и конкретной реализации контекста (MyOrmDataContext) это ведь их интимные дела. Зачем притягивать за уши к датаконтексту общий интерфейс, с методами Save, Delete, Get итд, если всё равно "что и как" получает репозиторий - только его сугубо личное дело. Нас (сервисный слой) интересует результат работы, а не конкретный процесс.

    Как я считаю было бы правильно (естественно - субъективно): перенести IDataContext в сборку DomainModel.MyOrmImplementation.

    ОтветитьУдалить
  26. Alexander Byndyu27 апреля 2010 г. в 09:07

    @zerkms
    Привет!

    IDataContext находится в сборке Infrastructure, которую используют другие проекты.

    Сборка DomainModel.MyOrmImplementation очень специфическая для проекта и в любой момент может быть заменена другой, либо часть реализаций репозиториев, которые использовали ORM1 могут начать использовать ORM2. Тогда опять же понадобится вынести IDataContext выше.

    Но, это конечно не правило, которое нельзя нарушать. Если аргументы, которые я описал выше не про твой проект, то перености IDataContext в DomainModel.MyOrmImplementation. Со временем рефактиринг покажет, как будет лучше ;)

    ОтветитьУдалить
  27. Georgy10 мая 2010 г. в 04:20

    Александр, извините за оффтоп :)

    Какой программой записывает видеокасты?

    ОтветитьУдалить
  28. Alexander Byndyu10 мая 2010 г. в 09:54

    @Georgy

    http://www.techsmith.com/camtasia.asp

    ОтветитьУдалить
  29. Unknown17 мая 2010 г. в 01:27

    Александр, спасибо! Очень подробно все - лучшее объяснение IoC, которое видел.

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

    ОтветитьУдалить
  30. Alexander Byndyu17 мая 2010 г. в 09:00

    @Maxim
    Я думаю, что такого описания нет.

    Конкретно про интерфейсы http://martinfowler.com/eaaCatalog/separatedInterface.html

    ОтветитьУдалить
  31. Warlock1 декабря 2010 г. в 15:25

    Александр хочу поблагодарить Вас за проделанную работу. Ваши статьи очень помогают встать на путь истинный :)

    У меня возникли некоторые сложности с реализаций подхода описанного в этой статье. Вернее сам подход мне понятен. Но вот такой момент, у Вас получается во всех интерфейсах есть явная зависимость от сущности. В частном случае от Product. А как быть если сущность моя есть сущность из Linq2Sql, а так как основная идея которую я хотел реализовать это не зависеть от ORM, то просто так это сделать не получается. И хотел бы спросить у Вас совета пока не нагородил какой нибудь велосипед. Читал у Вас статью про (TDD и LLBLGen Pro) но пока не удается удачно соединить ее и эту :)

    ОтветитьУдалить
  32. Alexander Byndyu1 декабря 2010 г. в 15:37

    @Warlock
    Рад, что помог.

    На самом деле это проблема всех ORM, которые занимаются генерацией кода. Я бы предложил вам перейти на NHibernate. Можете сразу воспользоваться готовой инфраструктурой из статьи Совершенный код №2. Пример реализации Unit Of Work с NHibernate.

    Иначе, доменные сущности придется наследовать от интерфейсов. Т.е. у Product будет IProduct. Это значительно увеличит кол-во кода и затруднит поддержку проекта.

    ОтветитьУдалить
  33. Unknown30 января 2011 г. в 22:54

    Добрый вечер.
    У меня вопрос по инверсии зависимостей и инжекции параметров в конструктор при использовании Ninject.

    Например у меня есть IRepositoiry с двумя обязательными параметрами в конструкторе. Его я инжектирую через конструктор в сервис. Сам сервис ижектирую в конструктор Presenter'a.

    Когда я описываю модуль для Ninject'a я могу binde'ить интерфейсы к реализациям. Как мне забайндить интерфейс репозитория к реализации, если у меня есть два параметра, которые будут определены в runtime? (параметры, например, указывают к каким БД подключаться. Это пользователь выберет из дроп дауна...)

    ОтветитьУдалить
  34. Alexander Byndyu31 января 2011 г. в 08:31

    @s-stude

    Это типичная проблема. Скорее всего вам придется создавать этот репозиторий не чего активную инжекцию, а через MyIoC.Resolve(connection)

    IoC контейнеры поддерживают передачу параметров в конструкторы при вызове Resolve.

    Либо вы можете передавать эти параметры в конкретный метод репозитория, который этими параметрами пользуется, т.е. убрать их из конструктора.

    ОтветитьУдалить
  35. Unknown31 января 2011 г. в 16:17

    Спасибо. Лучше это передавать в конструктор - параметр обязательный.

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...