но когда надо автоматически инжектить логгер с именем класса и с возможностью оверрайда этого имени — MEF уже не крут,
Я делал это в MEF. Вполне удобно. Принцип в создании nonshared логгирующего агента и в присвоении агенту имени в событии после импортов. Три понятных строчки кода.
использовать ленивую инициализацию зависимостей из текущего скоупа выполнения в single instance объект — MEF уже не крут
Ну это вообще мне непонятно. Физически один объект разделяется между скопами и каждый скоп хочет видеть в нем свои зависимости?
Если просто разделение объектов между областями — то это в MEF есть.
Лайфтайм менеджмент в MEF?
Думаю о том, чтобы написать по этому поводу статью. Почему бы нет? С созданием и областью видимости проблем не очень много, с ликвидацией проблем больше, хотя последнее, насколько мне известно, проблема не только MEF.
Лично мне нравится то, что MEF не дает собой оперировать как универсальной фабрикой — как, наверное, видно из пред-пред. поста, я считаю это плохой практикой. :)
Перехват вызовов — это не задача сама по себе, а способ решения какой-либо другой задачи.
MEF обеспечивает внедрение зависимостей (dependency injection) и это именно та характеристика, которая ассоциируется как определяющая для IoC контейнеров, если судить по статьям на хабре и вики. :) Остальное — это уже фантазия тех, кто реализует контейнер. То, что контейнеру можно приделать упомянутый выше перехват не значит, что это обязательная необходимость для IoC контейнера.
Жизненным циклом MEF управляет (т.е. самостоятельно создает и уничтожает объекты определенным политикой образом). И никакого жуткого колдунства и костылей не требуется, чтобы управлять жизненным циклом собственными политиками — хотя писать придется, да.
Таким образом, MEF является вполне полноценным контейнером, также как МАЗ является полноценным автомобилем, пусть и не очень подходящим под то, чтобы на нем на работу ездить.
Статья на MSDN кстати не утверждает, что MEF это не IoC-контейнер. Она говорит, что большинство IoC-фреймворков обладают более богатой функциональностью и можно, немножко дописав, реализовать функциональность MEF (равно как вы утверждаете, что, дописав MEF, можно реализовать функциональность этих фреймворков).
А в целом, за исключением терминологического спора о том, IoC-контейнер ли MEF или нет, мы с вами сходимся во мнении, что задача определяет использование или неиспользование этого самого MEF и с точки приложения к этой задаче сравнивать его можно с любыми другими контейнерами. :)
Подключился поздно, поэтому начну заново — MEF вполне полноценный контейнер, решающий конкретный класс композиционных задач. Если нужно делать хитрые манипуляции c лайфтаймом и перехватывать все этапы построения — юнити, конечно, подходит лучше. Если важнее наглядное, простое и декларативное управление композицией — то лучше, наверное, все-таки меф.
Ну и по вопросам — тестируется все прекрасно, тестируемые объекты складываются в тест-контейнер, дополняются заглушками того, что тестить не надо. Реализация IoC вполне законченная, но на своей практике я встречал людей, которым очень хочется использовать контейнер как фабрику на все случаи жизни и которые требуют от него кучу синтаксического сахара и возможностей, не связанных с композиционным IoC. А это приводит итоге к большой неразберихе.
Еще раз отрезюмирую — для использования с Prism MEF, как композиционный контейнер, подходит едва ли не лучше Unity. Уж точно не хуже. В общем случае надо рассматривать конкретные задачи.
Не очень понятно из статьи — убрана многомерная модель в принципе или только лишь терминология? Чем тогда отличается формирование аналитики от того, что было раньше?
Очень интересная фича, не знал о ней, правда и на vb почти не пишу. Хотя, опять же, для моей задачи (где надо еще и переменные в качестве значений атрибутов использовать) было бы тоже громоздко. Или оно умеет и переменные вставлять?
Конкретно эти два класса делались для написания тестов. Цель теста — определить некоторые входные данные, сформировать на их основе тестируемым алгоритмом xml и сравнить этот xml с эталонным образцом.
Соответственно, первая и основная цель — наглядно и быстро определить (ну и сравнить) этот самый Xml — чтобы тест был понятного вида. Синтаксис XDocument для определения xml все-таки более громоздок, хотя и более полнофункционален.
Я делал это в MEF. Вполне удобно. Принцип в создании nonshared логгирующего агента и в присвоении агенту имени в событии после импортов. Три понятных строчки кода.
Ну это вообще мне непонятно. Физически один объект разделяется между скопами и каждый скоп хочет видеть в нем свои зависимости?
Если просто разделение объектов между областями — то это в MEF есть.
Думаю о том, чтобы написать по этому поводу статью. Почему бы нет? С созданием и областью видимости проблем не очень много, с ликвидацией проблем больше, хотя последнее, насколько мне известно, проблема не только MEF.
Лично мне нравится то, что MEF не дает собой оперировать как универсальной фабрикой — как, наверное, видно из пред-пред. поста, я считаю это плохой практикой. :)
MEF обеспечивает внедрение зависимостей (dependency injection) и это именно та характеристика, которая ассоциируется как определяющая для IoC контейнеров, если судить по статьям на хабре и вики. :) Остальное — это уже фантазия тех, кто реализует контейнер. То, что контейнеру можно приделать упомянутый выше перехват не значит, что это обязательная необходимость для IoC контейнера.
Жизненным циклом MEF управляет (т.е. самостоятельно создает и уничтожает объекты определенным политикой образом). И никакого жуткого колдунства и костылей не требуется, чтобы управлять жизненным циклом собственными политиками — хотя писать придется, да.
Таким образом, MEF является вполне полноценным контейнером, также как МАЗ является полноценным автомобилем, пусть и не очень подходящим под то, чтобы на нем на работу ездить.
Статья на MSDN кстати не утверждает, что MEF это не IoC-контейнер. Она говорит, что большинство IoC-фреймворков обладают более богатой функциональностью и можно, немножко дописав, реализовать функциональность MEF (равно как вы утверждаете, что, дописав MEF, можно реализовать функциональность этих фреймворков).
А в целом, за исключением терминологического спора о том, IoC-контейнер ли MEF или нет, мы с вами сходимся во мнении, что задача определяет использование или неиспользование этого самого MEF и с точки приложения к этой задаче сравнивать его можно с любыми другими контейнерами. :)
Ну и по вопросам — тестируется все прекрасно, тестируемые объекты складываются в тест-контейнер, дополняются заглушками того, что тестить не надо. Реализация IoC вполне законченная, но на своей практике я встречал людей, которым очень хочется использовать контейнер как фабрику на все случаи жизни и которые требуют от него кучу синтаксического сахара и возможностей, не связанных с композиционным IoC. А это приводит итоге к большой неразберихе.
Еще раз отрезюмирую — для использования с Prism MEF, как композиционный контейнер, подходит едва ли не лучше Unity. Уж точно не хуже. В общем случае надо рассматривать конкретные задачи.
В чем Вы видите его неполноценность?
Соответственно, первая и основная цель — наглядно и быстро определить (ну и сравнить) этот самый Xml — чтобы тест был понятного вида. Синтаксис XDocument для определения xml все-таки более громоздок, хотя и более полнофункционален.