2013-09-20 3 views
0

Я пишу некоторые настраиваемые серверные элементы asp.net и ищет наилучшую практику в том, как вводить зависимость, которую требует контроль.Инъекция зависимостей в пользовательском контроле сервера ASP.NET

При решении вопроса о том, как это сделать, есть несколько факторов, которые я принимаю во внимание:

1) Как легко было бы внедрить эту зависимость с помощью разметки.
2) Насколько легко было бы вводить эту зависимость через код.
3) Эта инъекция должна быть как можно раньше в жизненном цикле управления, предпочтительно, чтобы элемент управления имел все свои зависимости, доступные в OnInit().

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

Пример:

public class MyControl : CompositeControl 
{  

    public string RepositoryType { get; set; }  
    protected IRepository Repository { get; set; } 

    protected override void OnInit() 
    { 
      EnsureChildControls(); 
    } 

    protected override void CreateChildControls() 
    { 
      if (!ChildControlsCreated) 
      { 
       Repository = ComponentFactory.Instanciate(RepositoryType); 
      } 
    } 
} 

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

+0

Обсуждались ли вы какие-либо схемы внедрения Injection, такие как Unity или NInject? Они автоматически вводят конкретный класс для вас во время выполнения на основе того, как вы его настраиваете. –

+0

На данный момент я бы предпочел не добавлять в систему еще одну переменную (фреймворк). Может быть, в будущем я проверю их. – BlueChameleon

+0

Это зависит от того, как вы создаете элемент управления. Если он динамически загружается через код, то инъекция зависимостей работает по-разному, если вы должны позволить серверу загружать его с помощью asp-тега (в одном из них у вас есть экземпляр, другой - за кулисами). Если вы загружаете с помощью asp-тега, в некоторых рамках вы можете применить к свойству атрибут, например '[Inject]', чтобы сообщить инжектору, какие зависимости нужно заполнить. – Matthew

ответ

1

Что я сделал, это инициализировать элемент управления, запросить контейнер DI и заполнить эти ссылки. Вы можете вложить эту логику в специализированный базовый класс, который может наследовать пользовательский серверный элемент управления, поэтому он повторно используется. ИЛИ: Существует специальный метод AddedControl, который вызывается каждый раз, когда элемент управления добавляется в дерево управления. Здесь предостережение состоит в том, что он, вероятно, вызывает метод только в родительском элементе управления и не поддерживает его. Он может работать в зависимости от вашего сценария.

В жизненном цикле мало что известно, когда создается элемент управления (кроме метода AddControl или метода Init, который запускается в начале процесса), и вы можете Не настраивайте конструктор элемента управления.

Что касается № 1, то для использования подхода разметки потребуется коснуться аспекта времени разработки элементов управления и максимально использовать атрибуты времени разработки. Но # 1 означает определение сопоставлений в разметке, что не совсем является точкой контейнера DI. Дизайнеру все еще нужно свойство или что-то, чтобы назначить ссылку, поэтому по существу это будет двойная работа по определению свойства, а затем определение чего-то в дизайнере, когда контейнер DI позаботится об этом для вас.

+0

Если я правильно понимаю, ваше решение не принимает во внимание, как установить DI из разметки. – BlueChameleon

+0

Это правда. Отредактировано выше. –

+0

Вы имеете право на разметку. Не имеет смысла назначать зависимости из разметки. Я думаю, что все это с DI заключается в том, что я всегда получаю перекручивание между компонентами, являющимися самоконтейнерами и все еще одноразовыми. благодаря – BlueChameleon

Смежные вопросы