工厂模式咨询需要，请

Question

我的工作在我的空闲时间，一个简单的数据存储项目用它包裹我周围的工厂模式头。这个想法是采用简单的数据，并使用VB.NET中的简单工厂模式将其保存到数据库中。我认为我对模式本身有一个基本的了解，然而，我正在努力的是如何将工厂类整合到架构中。我对这个项目看起来基本上是这样一个标准的3层架构：

介绍

-Presentation.Common 
-Presentation.DataStorageWebAppName 

业务

-BusinessLayer.Common 
-BusinessLayer.DataStorageAppName 

数据

-DataLayer.Common 
-DataLayer.DataStorageAppName 

常见

-Common 
-Common.DataStorageAppName 

个

接口

-Interfaces.Common 
-Interfaces.DataStorageAppName 

在哪些方面遇到麻烦架构的应用程序的特定场景，让我举一个例子。假设在业务层中，我在BusinessLayer.DataStorageAppName DLL中创建了一个名为Foo的类。它有一个接口IFoo，它存在于Interfaces.DataStorageAppName DLL中。为了通过使用简单工厂模式的IFoo接口创建类Foo的实例，现在，我在BusinessLayer.DataStorageAppName中创建一个Factory类，并编写一个共享/静态方法，通过IFoo接口为我提供实例。后来，据我了解，我可以决定换掉这个Factory类返回的对象，而不必做其他事情（理论上）。

要到这一点，这工作，但似乎什么时髦这件事是我现在被迫创建几个工厂类：基本上每一个DLL，让我能避免循环引用。有没有一种更清洁的方式来实施这些工厂类，而不诉诸像城堡温莎等第三方解决方案等。似乎我错过了这里的一个基本概念。看起来好像应该可以在负责分发对象实例的体系结构中拥有一个“存储库”（如果愿意的话）。

预先感谢您！

Answer 1

我参加了一个更简单的方法。我定义了一个实体类，并且我有一个产生实体列表的工厂（列表<实体>）。我告诉工厂我想回到哪些类型，它假设类型是表，属性是列，生成sql，获取数据，填充类型的新实例列表。

本厂还可以接收一个实体对象，并使用反射来获取在数据库中更新其值。

现在我需要做的唯一的事情就是创建一组实体类的对于给定的数据库，BTW是数据传输对象以及。

Answer 2

是否有一个原因，为什么你实现的IFoo，并返回它不能生活在从BusinessLayer一个单独的程序（这样的话你可以从所有的客户端组件引用此新组装）工厂方法？如果有原因，是否有可能在BusinessLayer中定义IFoo（因此不需要引用接口组件）？

如果您的界面确实需要从业务层以外的地方进行访问，并且实现真的依赖于业务层，那么您需要查看的不仅仅是工厂方法。您可以使用控制/依赖注入反转的一些原理来更好地分离关注点。

[编辑为回应O.P.随后的回答] 工厂方法不是IMO足以被视为IoC方法。最好的做法是封装特定实现的构建，以便在多个地方重复使用或简单地复制到sweep it under the rug。对我来说缺乏的是破坏依赖关系：由于你的工厂方法与被调用的工厂方法生活在同一个程序集中，为了改变返回的具体类型，你需要重新编译。考虑以下两者的区别：

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时。而且，如果它以某种方式动态地决定两个实现，则只有一个地方可以放置逻辑。另一个优点是，如果构造函数是复杂/丑陋的，或者需要一些额外的代码来查找配置设置等，那么它就隐藏了所有远离使用它的方法。

但是，这些都不是真的（至少在我看来）帮助您打破此方法与其使用的具体实现之间的依赖关系。

Answer 3

如果他们处理不同的问题，那么拥有多个工厂类并不一定很时髦。我建议不要使用静态工厂方法，而是创建您使用的工厂实例。然后工厂自己可以实现接口，也许一些funkiness消失。