Web-automation.ru

Библиотечный код полезно выносить в отдельный проект, для его повторного использования.

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

Предлагается некая вариация данного паттерна:

Пусть все классы в проекте будут internal , вся логика, которая должна быть доступна внешнему миру – объявляется в interface.

Но как внешнему коду достучаться до реальной реализации контрактов, если они видимы только в пределах своей сборки? Пусть некий главный фасадный класс с помощью IoC контейнера выполнит связывание интерфейсов с реализациями. И тогда внешний код, запрашивая интерфейс, получит реализацию.

Выглядит это следующим образом:

/* AS.Lib */public interface IDoSomething {
     void DoSomething();
}

internal class DoSomething : IDoSomething {
  public void DoSomething() {
     this.DoSomethingElse();
     new СкрытыйОтВнешнегоМираВспомогательныйКласс().HelpMeDoSomething();
  }
}

/* Facade */public class Facade {

   public void RegisterBindings(UnityContainer container){
     container.RegisterType(IDoSomething, DoSomething)
   }
}

/* External code */void Main(){
  var uContainer = new UnityContainer()
  AS.Lib.Facade.RegisterBindings(uContainer);
  uContainer.Resolve(AS.Lib.IDoSomething).DoSomething();
}

Более того, связывание можно настраивать, если требуется альтернативная реализация (см. паттерн Стратегия), подобно тому как принято настраивать Js-модули.