Контейнер IOC встраивает код против конфигурации. Необходим совет - PullRequest
Новая
       8

Контейнер IOC встраивает код против конфигурации. Необходим совет

1 голос
/ 04 июня 2011

Я не сделал много МОК, но из того, что я прочитал, и примеров, которые я вижу в Интернете, это смутило меня.

Насколько я понимаю, вам следует использовать МОК для продвижения слабосвязанной системы.

Теперь строим контейнер в коде (Unity), который использует моя компания, как его можно отделить, если мне нужно иметь жесткую ссылку на мой сервис EG 

   IUnityContainer container=new UnityContainer()
    .RegisterType<IMyService,MyService>();

Как видите, MyService - этоконкретный класс, который потребует, чтобы у меня была ссылка на мой уровень обслуживания.

Разве я не побеждаю точку сейчас?

Любые примеры или предложения или мнения очень приветствуются

Ответы [ 3 ]

2 голосов
/ 04 июня 2011

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

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

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

С точки зрения механики, вы можете упростить регистрацию и не упоминать оба типа каждый раз, и даже не иметь ссылки на другие сборки, используя условные обозначения в некоторых других контейнерах, таких как Windsor (Unity не поддерживает насколько мне известно, регистрация на основе конвенций).

Опять же - это механика, и она не имеет ничего общего со слабой или жесткой связью или причинами использования контейнеров. Это просто упрощает использование контейнера.

НТН

0 голосов
/ 05 июня 2011

Основной концепцией при создании контейнера IoC с помощью кода является Instability . Нестабильность является метрикой для объектно-ориентированных систем, измеряющих отношение эфферентной связи к полной связи. Это наиболее полезно при применении на уровне «пакета развертывания», который для .NET является сборкой.

При использовании этого показателя цель состоит не в том, чтобы все время достигать низкой нестабильности, а в том, чтобы повысить стабильность некоторых сборок (близких к 0 эфферентной связи) путем объединения нестабильности в другие сборки.

В зависимости от платформы, с которой вы работаете, ваш .Exe (или сборка, содержащая ваше HttpApplication, ServiceHost и т. Д.) Должен взять на себя ответственность за управление запуском приложения, его закрытием и агрегацией всех зависимостей, включая создание ваш IoC (это облегчит процесс развертывания, поскольку базовый сценарий развертывания требует, чтобы ваш исполняемый проект ссылался на любые зависимости).

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

  • Вы теряете возможность вручную создавать экземпляр (возможно, выполняя некоторую инициализацию, которая будет затруднена из-за конфигурации) перед регистрацией экземпляра, который будет разрешен для его интерфейса.
  • Проверка сборки - например, ошибочный ввод имени класса или имени интерфейса.
  • Простота развертывания. Если вы не ссылаетесь на сборки, содержащие реализации интерфейса в вашем основном проекте, вам придется вручную развернуть их или вручную добавить их в ваш проект установки (если вы его используете). Это может быть более или менее проблемой в зависимости от среды и любых существующих процессов развертывания, которые могут иметь место.
0 голосов
/ 04 июня 2011

На примере приложения MVC, конфигурация 

UnityContainer container = new UnityContainer()
    .RegisterType<IMyService, MyService>();

будет создано при запуске приложения, а преимущества будут получены при использовании IMyService, например, в контроллере: 

public class MyController : Controller
{
    private readonly IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    } 

    public ActionResults Index()
    {
        var model = _myService.GetModel();
        return View(model);
    }
}

Сравните это с системой, которая использует это следующим образом: 

public ActionResults Index()
{
    var model = new MyService().GetModel();
    return View(model);
}

Теперь вы женаты на этой реализации. Модульное тестирование становится очень сложным, так как нет способа высмеять IMyService.

...