TL;DR: пакет для легкой регистрации (и конфигурации) AutoMapper в Unity.
var container = new UnityContainer();
container.RegisterMappingProfile<DataModelToViewModel>();
container.RegisterMapper();
public SomeController(IMappingEngine mapper)
{
_mapper = mapper;
}
public ViewModel SomeAction()
{
return _mapper.Map<ViewModel>(dataModel)
}
О боже, ещё один пост о Inversion of Control
Каждый более-менее опытный программист встречал в своей практике словосочетание Инверсия управления (Inversion of Control). Но зачастую не все до конца понимают, что оно значит, не говоря уже о том, как правильно это реализовать. Надеюсь, пост будет полезен тем, кто начинает знакомится с инверсией управления и несколько запутался.
Уже в этот четверг, 23 октября, сообщество SPB Frontend совместно с «Зоной действия» проведут очередную встречу.
Ожидается доклад + QA-сессия от разработчиков из питерского Google и аж два доклада про dependency injection в современных фреймворках и вне их.
Понятия «инверсия управления» и «внедрение зависимостей» не являются новыми, но в сообществе JavaScript, несмотря на его бурный и продолжительный рост, почему-то встречаются довольно редко.
Независимо от контекста исполнения, расширяемое и поддерживаемое javascript-приложение, как и приложение, написанное на любом другом языке, должно соответствовать некоторым архитектурным принципам. Одним из которых является инверсия управления. Читать полностью »
Спасибо! И позвольте, я объяснюсь.
В первую очередь, спасибо всем, кто прочитал предыдущие части. Много интересных комментариев написали, и я понял, что должен объяснить, зачем я, собственно, всё это пишу? Зачем мне вообще нужно отделять контроллеры от фреймворка? Скорее всего, об этом не придется думать, потому что
Шансы, что контроллеры придется переносить на другой фреймворк, близки к нулю. (Рафаэль Домс)
В предыдущей части этой серии мы понизили связанность симфонийского контроллера и фреймворка, удалив зависимость от базового класса контроллера из FrameworkBundle. А в этой части мы избавимся от некоторых неявных зависимостей, которые появляются из-за аннотаций.
Читать полностью »
Обычно считается, что контроллеры — наиболее связанные классы в приложении. Как правило, на основании данных запроса они получают или сохраняют данные в базу данных, затем превращают данные или результат сохранения в HTML, который выступает в качестве ответа клиенту, который произвел запрос.
Получается, что контроллеры — повсюду, они соединяют те части приложения, которые обычно достаточно независимы друг от друга. Это сильно повышает связанность контроллеров: среди их зависимостей есть менеджер сущностей Doctrine, шаблонизатор Twig, базовый контроллер из FrameworkBundle, и прочее.
В этой записи я покажу, что этот уровень связанности совершенно не нужен. Я покажу вам, как значительно понизить связанность, предприняв всего несколько простых шагов. В результате мы получим контроллер, который можно будет повторно использовать в разных типах приложений, например, на базе Silex или даже Drupal.
Читать полностью »
Внесу и свой вклад в тренд темного программирования.
Многим из вас знакома дилемма: использовать ли DI в своем проекте или нет.
Поводы перехода на DI:
Доводы не использовать DI:
Допустим, у нас есть большой рабочий проект, принято решение: переводить на DI. Разработчики чувствуют свой потенциал, уровень мидихлориан в крови зашкаливает.
Путь тебя ждет тернистый и долгий, мой юный падаван.
Если проект большой и в нем много разработчиков, одним коммитом вряд ли удастся сделать такой рефакторинг. Поэтому мы используем несколько плохих практик, упростив переход, а затем от них избавимся.
Читать полностью »
Зачем нужно внедрение зависимостей? Оно уменьшает связанность компонентов в приложение и упрощает тестирование. У некоторых разработчиков есть мнение, что внедрение зависимостей нужно только в больших проектах и что оно сильно усложняет программы. Думаю, это исторически сложилось из-за популярный фрейморков вроде Спринга или Джуса в Джаве. Особенно из-за Спринга, который является невероятным комбайном.
Python-inject — это небольшая библиотека для внедрения зависимостей в Питоне. Третья версия написана в unix-стиле, т.е. она прекрасно выполняет только одну фукнцию и не пытается быть всем. В отличие от уже упомянутых Спринга и Джуса Инжект не ворует конструкторы классов у разработчиков, не навязывает разработчикам необходимость писать приложение в каком-то определенном стиле и не пытается управлять всем графом объектов приложения.
Инжект практически не требует конфигурации (об этом подробнее подкатом) и очень прост в использовании.
# Возможные зависимости
class Db(object): pass
class Mailer(object): pass
# Внедряем зависимости в класс пользователя
class User(object):
db = inject.attr(Db)
mailer = inject.attr(Mailer)
def __init__(self, name):
self.name = name
def register(self):
self.db.save(self)
self.mailer.send_welcome_email(self.name)
# Используем в тестах inmemory базу данных и моки.
class TestUser(unittest.TestCase):
def setUp(self):
inject.clear_and_configure(lambda binder: binder
.bind(Db, InMemoryDb())
.bind(Mailer, Mock()))
self.mailer = inject.instance(Mailer)
def test_register__should_send_welcome_email(self):
# Пример теста.
user = User('John Doe')
# Регистрируем нового пользователя.
user.register()
# Должно отправиться письмо с приветствием.
self.mailer.send_welcome_email.assert_called_with('John Doe')
В своих двух предыдущих статьях я рассказал о Dependency Injection и IoC контейнере, и о том, как они работают конкретно в Laravel. Данный пост будет посвящен практическому применению DI и IoC на реальном примере. А так же, какие все таки преимущества нам дают эти два прекрасных инструмента и паттерна в приложении.