Должны ли конкретные объекты всегда возвращаться фабричным методом при использовании интерфейса?

Question

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

 IRepository<User> userRepository = new UserRepository(connection); // Needs a dbconnection
 userRepository.Create(user);

 //Is this the best way?
 IRepository<User> userRepository = RepositoryFactory.GetUserRepository(connection);

 public static class RepositoryFactory
 {
    public static IRepository<User> GetUserRepository(DbConnection connection)
    {
        return new UserRepository(connection);
    }
 }

Каков наилучший из наиболее логичных способов заставить работать объект UserRepository? Если я использовал объект фабрики для UserRepository, я передаю объект соединения или что это за процесс?

Answer 1

Как сказал Джон, вы можете использовать МОК. Но это справедливо только в том случае, если вы считаете, что хотели бы иметь этот дополнительный уровень развязки в вашем приложении. Также было бы намного проще заглушить / издеваться, если вы используете IoC. Но я знаю, что иногда введение нового движущегося элемента в ваш проект может быть болезненным.

Фабрика действительно могла бы пойти по этому пути. Я бы передавал абстракцию высокого уровня на заводе. Строка или перечисление, которое говорит что-то вроде «FromADatabase» или «FromANetwork». Это до завода, чтобы найти соответствующие детали конструкции для того, что вы хотите (из файла конфигурации, например), построить необходимый конкретный объект и передать его обратно.

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

Answer 2

Извините, если я неправильно прочитал ваш вопрос, но вы можете взглянуть на

Инверсия управления и Инъекция зависимости и посмотрите, как они лучше всего подходят для того, что вы пытаетесь сделать.

IoC: http://visualstudiomagazine.com/articles/2010/08/01/inversion-of-control-patterns-for-the-microsoft-net-framework.aspx / http://joelabrahamsson.com/entry/inversion-of-control-introduction-with-examples-in-dotnet

Внедрение зависимостей: http://www.blackwasp.co.uk/DependencyInjection.aspx