Существует ли причина, по которой ваша реализация IFoo и метода фабрики, который возвращает его, не может находиться в отдельной сборке от BusinessLayer (и, таким образом, вы можете ссылаться на эту новую сборку из всех клиентских сборок)? Если есть причина, возможно ли, что IFoo должен быть определен также в BusinessLayer (и, следовательно, не требует ссылок на сборку интерфейсов)?
Если ваш интерфейс действительно должен быть доступен не из бизнес-уровня, а реализация действительно зависит от бизнес-уровня, вам нужно взглянуть на нечто большее, чем просто фабричный метод. Вы можете использовать некоторые принципы Инверсии Контроля / Внедрения Зависимостей, чтобы лучше разделить проблемы.
[Изменить в ответ на последующий ответ О.П.]
Фабричный метод, IMO, не достаточен, чтобы считаться подходом IoC. Лучше всего инкапсулировать конструкцию конкретной реализации, для повторного использования в нескольких местах или просто для подметания под коврик . Чего мне не хватает, так это разрыва зависимостей: поскольку ваш фабричный метод находится в той же сборке, из которой он вызывается, для изменения возвращаемого конкретного типа вам потребуется перекомпилировать. Рассмотрим разницу между следующими двумя:
public class FooConsumer1
{
public void DoStuff()
{
IFoo myFoo = new Foo();
myFoo.Bar();
}
}
и
public class FooConsumer2
{
public void DoStuff()
{
IFoo myFoo = FooFactory.getFoo();
myFoo.Bar();
}
}
public class FooFactory
{
public static IFoo GetFoo()
{
return new Foo();
}
}
Преимущество второго состоит в том, что если вы создаете IFoo более чем в одном месте, у вас есть только одно место, чтобы изменить его, когда вы создаете класс SuperFoo для замены Foo. Кроме того, есть только одно место для размещения логики, если она каким-то образом будет динамически выбирать между двумя реализациями. Другое преимущество состоит в том, что если конструктор сложен / безобразен или требует некоторого дополнительного кода для поиска параметров конфигурации или чего-то подобного, то он скрывает все это от метода, который его использует.
Однако, ни один из них на самом деле (по крайней мере, на мой взгляд) не помогает вам сломать зависимости между этим методом и конкретной реализацией, которую он использует.