11

我已经越来越熟悉工厂模式（以及策略模式）以及该模式可以带来的巨大好处。但是，我一直在努力应对以下情况：

以前，我会做类似以下的事情，其中​​有一个可以构建和保存汽车的管理器类。这里没有依赖注入，实现起来很糟糕，尤其是在尝试进行单元测试时。

public class CarManager
{
    public static Car GetCarFromDatabase(int carId) { return new Car(); }

    public static void SaveCar(Car car) { }
}

我现在看到了如何Factories为我制造不同的汽车，无论是来自数据库还是其他任何地方！这很棒！所以，这是我的问题：

Q1：我的理解Factories应该只构建对象，对吗？如果是这样，那我的第二个问题呢？

Q2：如果我遵循工厂模式来构建我的对象，我应该如何保存我的对象？是否有不同的模式，或者我没有完全理解工厂模式？

4

5 回答 5

16

工厂模式应该有助于创建对象。这就是为什么它被归类为“创造”模式。要回答您的第一个问题，它不应该用于持久化对象。

存储库模式是一种持久性模式，应该用于将对象保存到某种持久性机制或从持久性机制中检索数据。根据 Martin Fowler 的说法，这实际上是一种与典型设计模式不同的企业模式。

当考虑你的问题时，你想看看SOLID 中的 S 原则，它指出一个类应该有一个单一的责任，这意味着它应该有一个改变的理由。在这种情况下，当谈论创建对象以及保存（持久化）对象的对象时，您有一个有两个更改原因的类。现在，它看起来可能是一个单一的职责，因为存储库可以检索对象并将其保存到您的应用程序中，并且检索看起来像一个工厂（并且通常是存储库中的工厂对象），但是在您所描述的内容中，你的对象有太多的责任。

于 2010-10-27T17:06:20.613 回答
3

工厂不应保存数据。数据访问对象 (DAO) 或表映射器将是一个更好的主意。

于 2010-10-27T17:05:29.700 回答
2

一切都取决于您的需求以及您想如何做事，模式是没有标准的实践，它们鼓励代码重用，模式不是一成不变的。那么，为什么不应该使用工厂模式来使对象持久化呢？这就是我如何使用这种模式来解决从/向不同数据库读取/写入数据的问题，也许这不是使用该模式的更好形式，但它目前正在工作，可扩展，分布在各层之间，几乎大家可以理解：

namespace Domain.App
{
    public class PresentationClass
    {
        private Collection<ISomeOutput> GetData(ISomeInput1 input)
        {   
            ServicesLogicContext logic = new ServicesLogicContext( (MyType) Identifier );
            return logic.GetSomeData(input) as Collection<ISomeOutput>;
        }
        private IMethodResult ExecuteSomeAction(ISomeInput2 input)
        {   
            ServicesLogicContext logic = new ServicesLogicContext( (MyType) Identifier);
            return logic.ExecuteSomeAction(input);
        }
    }
}   

namespace Domain.Logic
{
    public sealed class ServicesLogicContext : ServicesLogicContextBase
    {
        public IList<ISomeOutput> GetSomeData(ISomeInput1 input) 
        {
            DBServices services = DBServicesProvider.CreateServices(SomeIdentifier);
            return DBServicesProvider.GetSomeData(input);
        }
        public IMethodResult ExecuteSomeAction(ISomeInput2 input)
        {
            DBServices services = DBServicesProvider.CreateServices(SomeIdentifier);
            IMethodResult result = services.ExecuteSomeAction(input);
            return result;
        }
    }
}

namespace Domain.Data
{
    public abstract class DBServices : IServices
    {
        public virtual IList<ISomeOutput> GetSomeData(ISomeInput1 input)  {...}
        public virtual IMethodResult ExecuteSomeAction(ISomeInput2 input) {...}
    }

    public class DBServicesSpecific1 : DBServices
    {
        public override IList<ISomeOutput> GetSomeData(ISomeInput1 input)  {...}
        public override IMethodResult ExecuteSomeAction(ISomeInput2 input) {...}
    }

    public class DBServicesSpecific2 : DBServices
    {
        public override IList<ISomeOutput> GetSomeData(ISomeInput1 input)  {...}
        public override IMethodResult ExecuteSomeAction(ISomeInput2 input) {...}
    }

    public sealed class DBServicesProvider
    {
        public static DBServices CreateServices(MyType identifier)
        {
            DBServices result = null;       
            switch(identifier) 
            {
                case MyType.Specific1: result = new DBServicesSpecific1(); break;
                case MyType.Specific2: result = new DBServicesSpecific2(); break;       
            }
            return result;
        }
    }
}
于 2010-10-27T21:06:12.470 回答
1

总的来说，我认为你从错误的角度来处理这个问题。

您需要确定您要解决的问题，然后寻找适合该问题的解决方案。在我看来，这听起来更像是您发现了某种模式，然后试图将其应用于您遇到的每个问题。

您在发布的代码中提到的唯一问题是单元测试并不容易。使类更具可测试性的一种解决方案是反转它们的依赖关系。所以我会开始研究这个类所依赖的其他类，并开始制作那些可注入的依赖项。作为起点，我建议您阅读依赖反转/控制反转。

于 2010-10-27T17:13:37.650 回答
1

Q1 - 是的，工厂模式应该理想地用于创建对象。因此，您可以使用工厂模式创建 Car 对象。

Q2 - 为了保存你的汽车对象，你不应该使用工厂模式。解耦 Car 对象的创建和保存 car 对象。而且，如果不准确理解需求，就很难建议一种设计模式来保存您的汽车对象。在我看来，如果您只需要保存汽车对象，那么您可能需要的只是汽车管理器类中的保存方法。不要过度使用设计模式。

于 2010-10-27T17:14:38.653 回答