Я не встречал хорошего описания паттерна Dependency Injection применительно к PHP.

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

Я вспомнил еще об одной библиотеке для DI, Phemto. Ее автор, — Маркус Бэйкер, создатель SimpleTest. К сожалению на сайте содержится краткая и невнятная справка. тем не менее, проект развиавется, а внутри дистрибутива лежит статья с крайне хорошим объяснением про DI, ну и руководством конечно. Phemto, — очень миниатюрный проект, состоящий из трех не очень больших файлов.

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

Продолжение, начало в Части 1

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

Scala — лаконичный, элегантный и статически типизированный язык программирования, который сочитает в себе возможности обьектно-ориентированного и функционального языка. Scala полностью совместима с Java.

Сегодня я хотел бы показать вам, как, используя богатые выразительные способности этого языка, решить проблему, актуальную для любого более-менее крупного проекта, а именно работу с зависимостями компонентов или dependency injection. Последние несколько лет я использовал spring ioc для решения этой проблемы, однако у этого фрэймворка есть несколько недостатков, самый очевидный из которых это сборка приложения из компонент в runtime и наличие xml-дескрипторов (да, конечно можно использовать и autowiring и аннотации, но и у этих возможностей есть свои серьезные проблемы).

Популярный DI-контейнер вышел во второй версии. Кроме того, вышла версия Unity 2.0 для Silverlight 3/4.

Полезные ссылки:

• скачать Unity 2.0
• скачать Unity 2.0 for Silverlight
• документация Unity 2.0 Final Doc Set
• документация Microsoft Unity 2.0
• документация Microsoft Unity 2.0 for Silverlight

Качаем, читаем, делимся опытом :-)

Не так давно на Хабре была опубликована статья (ссылка на топик) моего коллеги AlexanderByndyu, описывающая уход от использования Repository в сторону применения связки QueryFactory + классы запросов Query. При этом в комментариях разгорелся весьма интересный диспут, касающийся целесообразности приведенного в статье решения. Было достаточно много интересных отзывов, среди которых особенно выделялись высказывания о том, что, дескать, QueryFactory не нужен и является лишней обузой, мешающей безболезненному добавлению, изменению и удалению классов запросов. В данной статье я хочу показать подход, который позволяет избавиться от применения QueryFactory, через активное использование IoC контейнера. Данную организацию работы со структурой классов запросов мы использовали в одном из наших недавних проектов, где в качестве IoC использовался Castle.Windsor.

Думаю сейчас слова IoC, DI, IoC-контейнер, как минимум у многих на слуху. Одни этим активно пользуются, другие пытаются понять, что же это за модные веяния.

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

В рамках JSR-299 “Contexts and Dependency Injection for the Java EE platform” (ранее WebBeans) была разработана спецификация описывающая реализацию паттерна внедрения зависимости, включенная в состав Java EE 6. Эталонной реализацией является фреймворк Weld, о котором и пойдет речь в данной статье.

К сожалению в сети не так много русскоязычной информации о нем. Скорее всего это связано с тем, что Spring IOC является синонимом dependency injection в Java Enterprise приложениях. Есть конечно еще Google Guice, но он тоже не так популярен.

В статье хотелось бы рассказать об основных преимуществах и недостатках Weld.

Доброго времени,

Как известно, Resharper решает много проблем по работе с кодом, но все-таки не все.

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

Хочу рассказать Java-сообществу Хабра о небольшом, но очень полезном (на личном опыте) фреймворке под названием Green-forest. Данный фреймворк можно использовать как самостоятельно, так и в контексте JEE или Spring.

Как с помощью него можно упростить код приложения узнаем под катом.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

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

Для связи всех частей воедино, Prism приложения полагаются на DI контейнер. DI контейнеры уменьшают зависимости между объектами, предоставляя способ создания экземпляров классов и управления их временем жизни в зависимости от конфигурации контейнера. При создании объектов с помощью контейнера, он инжектирует в них необходимые зависимости. Если зависимости ещё не были созданы, то контейнер в начале создаёт их и разрешает их собственные зависимости. В некоторых случаях, сам контейнер внедряется как зависимость. Например, при использовании Unity, в модули внедряется контейнер для того, чтобы они могли зарегистрировать в нём свои представления и службы.

Есть несколько преимуществ использования контейнера:

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

В контексте приложения, основанного на библиотеке Prism, есть определённые преимущества использования контейнера:

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

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

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

Асинхронную логику я решил реализовывать через механизм async/await, а готовые к работе компоненты регистрировать в Unity.

Привет всем!
Это вольный перевод статьи How to Build Your Own Dependency Injection Container.
Т.к. это мой первый перевод для хабра, прошу указывать на ошибки, неточности.

Как создать свой собственный Dependency Injection Container.

Поиск “dependency injection container” на packagist на данный момент выдает более 95 страниц результата. С уверенностью можно сказать, что это особое “колесо” уже изобретено.

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

В этой статье мы собираемся учиться делать простой dependency injection container пакет. Весь написанный в статье код плюс PHPDoc аннотации и unit-тесты с 100% покрытием доступны на GitHub. Все это так же добавлено на Packagist.

Откуда же начинаются опасности? Допустим вы твердо решили, что будете разрабатывать проект, придерживаясь определенной концепции или подхода. В нашей ситуации это DI, хотя на его месте также может оказаться, например, Реактивное Программирование. Вполне логично, что для реализации вашей цели, вы обратитесь к готовым решениям (в нашем примере — контейнер DI Zenject). Вы ознакомитесь с документацией и начнете строить каркас приложения, используя основной функционал. Если на первых порах использования решения у вас не возникнет неприятных ощущений, то скорее всего, оно задержится на вашем проекте на всю его жизнь. По мере работы с базовыми функциями решения (контейнера) у вас могут возникать вопросы или желания сделать некоторый функционал более красивым или эффективным способом. Наверняка, в первую очередь вы обратитесь за этим к более продвинутым «фичам» решения (контейнера). И на этом этапе может возникнуть следующая ситуация: вы уже неплохо знаете и доверяете выбранному решению, в силу чего многие могут не задуматься насколько идеологически правильным может быть использование того или иного функционала в решении, или переход к другому решению уже является достаточно дорогим и нецелесообразным (например приближается deadline). Вот на этом этапе и может возникнуть самая опасная ситуация — функционал решения применяется с малой осторожностью, или в редких случаях просто на автомате (бездумно).

Введение

Каждый начинающий разработчик должен быть знаком с понятием Inversion of Control (Инверсия управления).

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

Инверсия управления (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах и входящий в пятерку важнейших принципов SOLID.

На сегодня существуют несколько основных фреймворков по этой теме:

1. Dagger
2. Google Guice
3. Spring Framework

По сей день пользуюсь Spring и частично доволен его функционалом, но пора бы попробовать что-то и свое, не правда ли?

Три года назад, я написал статью о DI библиотеке для языка Swift. С того момента библиотека сильно измененилась и стала лучшей в своем роде достойным конкурентом Swinject, превосходящяя его по многим показателям. Статья посвящена возможностям библиотеки, но и имеет теоретические рассуждения. Итак, кому интересны темы DI, DIP, IoC или кто делает выбор между Swinject и Swinject прошу под кат:

Добрый день!

В этой статье я расскажу о том как я внедрял паттерн MVP в своём Windows Forms приложении и опишу практические ситуации и особенности использования IoC и ApplicationController. Переход от codebehind к MVP мне позволил:

• улучшить читатемость за счёт лучшего разделения кода (SRP) — отделить BL от View;
• выработать методику дальнейшего расширения функциональности приложения;
• избавиться от singleton, который я использовал для работы с настройками приложения.