1

我正在努力在我的空闲时间通过在一个简单的数据存储项目中使用它来围绕工厂模式。这个想法是使用 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 中创建了一个工厂类，并编写了一个共享/静态方法来通过 IFoo 接口给我一个实例。后来，据我了解，我可以决定换掉这个 Factory 类返回的对象，而无需做很多其他事情（理论上）。

言归正传，这是可行的，但似乎很奇怪的是，我现在被迫创建了几个工厂类：基本上每个 DLL 一个，这样我就可以避免循环引用。有没有一种更简洁的方法来实现这些工厂类，而无需使用诸如温莎城堡等 3rd 方解决方案。似乎我在这里错过了一个基本概念。如果您愿意的话，似乎应该可以在负责分发对象实例的体系结构中拥有一个“存储库”。

先感谢您！

4

3 回答 3

1

我采取了一种更简单的方法。我定义了一个实体类，并且我有一个生产实体列表（List<Entity>）的工厂。我告诉工厂我想要返回什么类型，它假设类型是表，属性是列，生成 sql，获取数据，填充该类型的新实例列表。

工厂还可以接收实体对象并使用反射来更新其在数据库中的值。

现在我唯一需要做的就是为给定的数据库创建一组实体类，顺便说一句，它们也是数据传输对象。

于 2008-12-29T21:32:28.507 回答
1

为什么您的 IFoo 实现和返回它的工厂方法不能存在于与 BusinessLayer 不同的程序集中（因此您可以从所有客户端程序集中引用这个新程序集），是否有原因？如果有原因，是否有可能 IFoo 也应该在 BusinessLayer 中定义（因此不需要对 Interfaces 程序集的引用）？

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

[根据 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时，你只有一个地方可以改变它。此外，如果它会以某种方式动态地在两个实现之间做出决定，那么只有一个地方可以放置逻辑。另一个优点是，如果构造函数复杂/丑陋，或者需要一些额外的代码来查找配置设置等，那么它会将所有这些隐藏在使用它的方法之外。

然而，这些都不是真的（至少在我看来）帮助你打破这个方法和它使用的具体实现之间的依赖关系。

于 2008-12-30T11:25:48.980 回答
0

It doesn't have to be funky to have several factory classes, if they handle different concerns. I would advice not to use static factory methods, but rather create instances of the factories you use. Then the factories themselves can implement interfaces, and perhaps some of the funkiness goes away.

于 2008-12-31T00:34:04.973 回答