Нужен совет по заводскому шаблону

Я выбрал более простой подход. Я определил класс Entity, и у меня есть фабрика, которая создает список объектов (List‹ Entity >). Я сообщаю фабрике, какие типы я хочу вернуть, она предполагает, что типом является таблица, а свойствами являются столбцы, генерируется sql, получает данные, заполняет список новых экземпляров типа.

Фабрика также может получать объект Entity и использовать отражение для обновления его значений в базе данных.

Теперь единственное, что мне нужно сделать, это создать набор классов Entity для данной базы данных, которые, кстати, также являются объектами передачи данных.

Есть ли причина, по которой ваша реализация IFoo и фабричный метод, который ее возвращает, не могут находиться в сборке, отдельной от BusinessLayer (и, таким образом, вы можете ссылаться на эту новую сборку из всех клиентских сборок)? Если есть причина, возможно ли, что IFoo также должен быть определен в BusinessLayer (и, следовательно, не требует ссылок на сборку интерфейсов)?

Если ваш интерфейс действительно должен быть доступен не только с бизнес-уровня, а реализация действительно зависит от бизнес-уровня, вам нужно взглянуть на что-то большее, чем просто фабричный метод. Вы можете использовать некоторые из принципов Inversion of Control/Dependency Injection, чтобы лучше разделить проблемы.

[Редактировать в ответ на последующий ответ от OP] Фабричный метод, 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. Кроме того, есть только одно место для размещения логики, если она каким-то образом будет динамически выбирать между двумя реализациями. Еще одно преимущество заключается в том, что если конструктор сложен/уродлив или требует некоторого дополнительного кода для поиска параметров конфигурации и т. д., то он скрывает все это от метода, который его использует.

Однако ни один из них на самом деле (по крайней мере, на мой взгляд) не поможет вам разорвать зависимости между этим методом и конкретной реализацией, которую он использует.

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