gusev_p Jan 23 2015 at 07:25

Simple container

18 min

12K

Контур corporate blog.NET*Designing and refactoring*C#*ООP*

+10

Comments 20

posledam Jan 23 2015 at 07:56

Всё таки хотелось бы узнать парочку значимых преимуществ велосипеда перед одним из выбранных популярных контейнеров (Autofac, Unity, Ninject), кроме одного очевидного — вносить непосредственно в ядро любые свои хотелки. Спасибо.

gusev_p Jan 23 2015 at 08:05

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

lair Jan 23 2015 at 08:16

Я специально глубоко не исследовал популярные контейнеры — в наших условиях удобнее велосипед заточить было.

Что же это за условия такие?

Но, насколько могу судить, чего-то похожего на контракты нет ни в одном из них.

Ну, у вас какое-то очень свое понимание термина «контракт». Но вообще на Unity такое можно сделать через расширения.

gusev_p Jan 23 2015 at 09:04

Что же это за условия такие?

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

Но вообще на Unity такое можно сделать через расширения.

Вы не могли бы пример привести?

lair Jan 23 2015 at 09:11

желание контролировать инфраструктуру и легко менять ее под потребности

БД у вас тоже своя? Операционная система?

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

Вот в этот момент и надо было смотреть на контейнеры, в которых эта логика есть. А лучше — в момент накручивания фич.

Вы не могли бы пример привести?

Сходу — нет, надо думать и писать.

gusev_p Jan 23 2015 at 09:54

БД у вас тоже своя? Операционная система?

Суть в том, что DI-контейнер — штука, неизмеримо более простая, чем БД или операционная система. В идеале конечно-же мне хотелось бы целиком контролировать БД и ОС чтобы иметь возможность быстро править там баги и добавлять нужные мне фичи. И в другом масштабе (google, microsoft) это так и происходит.

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

lair Jan 23 2015 at 10:01

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

posledam Jan 23 2015 at 08:25

Конечно выбор понятия «Контракты» под ваши задачи не очень удачный, так как сильно разнится с уже существующими «Контрактами» в C# и может внести путаницу для программиста. И конечно же данная задача легко решается в Autofac (именованные контексты, использование контейнера, как фабрики с именованными параметрами, передающиеся прямо в конструктор, реализация своей фабрики и билдеров в том числе с поддержкой своих атрибутов), поэтому я и спросил, ведь логично перед изобретением велосипеда как следует изучить уже доступные решения.

gusev_p Jan 23 2015 at 09:32

Как раз на Autofac я смотрел более пристально, чем на остальные, и аналогов не нашел. Здесь описано, как можно выбрать конкретную реализацию интерфейса в точке использования интерфейса — на уровне параметра конструктора типа ISender я могу атрибутом указать, что использоваться на самом деле должен EmailSender. Либо тоже самое можно сделать в соответствующей ему конфигурации. Контракты же в некотором смысле более общий механизм. Атрибутом я могу пометить не сам интерфейс, а целое дерево сервисов, которое где-то в своих листьях имеет замыкания на этот интерфейс. Деревья, помеченные разными атрибутами, будут автоматически созданы контейнером в нескольких экземплярах, т.к. имеют различные конфигурации для своих листьев. Основной пример — сложная бизнес-логика, реализуемая деревом сервисом и замыкающася на некоторый источник данных. В одном месте мне может быть нужно создать все это сложное дерево поверх файлового источника, а в другом — поверх базы данных. Причем у меня в системе будет всего два таких сервиса — контракты позволяют дать каждому из них имя и использовать по мере надобности в различных частях системы.

posledam Jan 23 2015 at 10:10

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

gusev_p Jan 23 2015 at 10:39

Согласен, что создание экземпляра — относительно дешевая операция, даже с учетом gc/memory traffic. Основной профит синглтонов — в их простоте для прикладного кода. Чтобы использовать внутри сервиса другой сервис нужно просто принять его в конструкторе. Точка использования ничего не знает о lifestyle-ах/dispose-ах — довольно второстепенных, по сути, вещах. Чтоб получить сервис, обладающий определенными характеристиками, нужно просто повесить на параметр конструктора атрибут с выразительным именем, а все эти характеристики формализовать в конфигураторах.

StanEgo Jan 23 2015 at 11:47

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

AlexeySuvorov Jan 23 2015 at 14:38

Спасибо что поделились своим опытом.
Оставлю это тут, может кому поможет при выборе контейнера

docs.autofac.org/en/latest/advanced/keyed-services.html

public class ArtDisplay : IDisplay
{
  public ArtDisplay([WithKey("Painting")] IArtwork art) { ... }
}

Razaz Jan 23 2015 at 08:16

Вроде все, что вы перечислили можно сделать на Autofac. За примерами далеко ходить не надо. Достаточно посмотреть что вытворяют с ним парни из OrchardCMS.

Имхо лучше бы помогали Autofac, Structuremap или Windsor.

aisek Jan 23 2015 at 09:17

Когда я ещё работал в Эльбе, там использовался как раз Windsor. И переход на robocontainer, а потом на свою реализацию, был как раз вызван неудобством его использования.

Razaz Jan 23 2015 at 12:02

Я сам не фанат виндзора, но Autofac сейчас имхо покрывает практически любые, даже самые дикие сценарии. А еще пачка вопросов:
Какая лицензия на исходники вашего контейнера?
Где codestyle, политика на пул реквесты?
Кто за это отвечает?
Какое комьюнити у вашего проекта?
Кто им пользуется?
Протестирован ли он на уровне Autofac?
Когда будет поддержка Asp.Net 5 на CoreClr?
Где nuget пакеты?

gusev_p Jan 23 2015 at 11:06

Этот контейнер отличается от Autofac, Structuremap и т.п. тем, что никогда не являлся самоцелью. В нем реализованы только те фишки, которые смогли существенно облегчить нам жизнь при решении конкретных задач. Поэтому, в частности, там нет понятия lifestyle-а — хоть и красивого теоретически, но приводящего к определенным сложностям в использовании и стыковке с другими фичами контейнера.

Уверен, что кое-что из описанного можно реализовать поверх Autofac — весть вопрос в том, какими усилиями и насколько простой код/конфигурация в итоге получится.

Razaz Jan 23 2015 at 11:56

Из того. что вы привели, большая часть уже есть в Autoаac. И как раз реализовать все достаточно просто.

Vadimyan Jan 23 2015 at 14:38

Мы используем такое решение для автофабрик. Да, вдохновлял Autofac, но на вкус и цвет последний не приглянулся, Unity как-то более поддерживаем сообществом.

Newbilius Jan 26 2015 at 05:37

К слову говоря, контейнер с минимальными правками переезжает на PC (Portable Class Library), после чего его вполне можно использовать для, например, мобильной разработки под Xamarin (iOS, Android) и Windows Phone. Как только протестируем его в боевых условиях, наверняка сможем выложить такую сборку.