Question

计划使用构建器模式，但是我不确定是否使用正确的方法。这里， 1）从数据库或API中提取数据并构造对象2）发布到API

如此，看起来，此套件适用于Builder设计模式，如下所示：

我没有看到使用构建器模式通过从数据库读取数据来构造对象的示例。从数据库或API检索的数据中压缩对象时是否合适的模式OrElse，其设计错误？示例：

public class ResultBuilder
{

    private IList<Parts> _parts; 
    private IList<Dealers> _dealers;

private int resultSetId;
    public ResultBuilder(int resultSetId)
    {
        this.resultSetId = resultSetId;
    }

    public ResultBuilder PrepareParts()
    {
        //call to PartsService and pull from database based on resultSetId and prepare List<Parts>.

    }
public ResultBuilder PrepareDealer()
    {
        //call to DealerService and pull from database and prepare List<Dealer>.

    }

    public IList<Dealers> Build()
    {
        //Build Dealers and Parts mapping for Dealer.Parts and return;
        //submit to another service.
    }
}

客户端：ResultBuilder.PrepareParts().PrepareDealer().Build();

Answer 1

以这种方式使构建器填充对象的主要问题是，您的构建器将仅能够以这种方式创建事物。

例如，下个月，您可能会发现需要使用来自其他地方的相似数据来构建这些对象之一。

通过保留构建者作为构建者并使用separation of concerns（或“单一责任原则” ：来自SOLID的S）会更加灵活一个不同的类来协调获取数据并将其传递给构建器。

按照您所描述的方式进行“错误的设计” 是吗？设计决策是非常主观的，应基于当时的已知和预期要求。例如，针对我建议的设计原则是YAGNI和Rule of Three。

换句话说，您必须在灵活性的增加与代码数量的增加之间取得平衡。

Answer 2

除非这是一家商店，否则不确定是否可以“建立”经销商。而是将Dealer作为Director对象，该对象调用其自己的Construct方法，该方法接受Builder对象作为参数。

构建器模式需要一个由1个或多个Builder类组成的Director类。构建器类生成零件。

您可以创建一个抽象的Builder类，并为摩托车，汽车或船舶零件提供具体的Builder。这些构建器提供了一种方法来返回其托管的产品（在此实例中为零件）。

Answer 3

您应该考虑步骤PrepareParts().PrepareDealer()是否是强制性的，以及是否可以省略它们。而且，就此而言，操作顺序是否重要。

如果所有步骤都是强制性的，并且必须按顺序执行，那么构建器不是一个好方法。

接下来应该考虑的是是否要更改步骤数据的提供者。然后，您需要将某种依赖项注入到构建器中。例如，您可能想从数据库，磁盘或Web服务中获取资源。

最后，您应该考虑这段代码应该做什么：

var rb1 = ResultBuilder.PrepareParts()
var rb2 = rb1.PrepareDealer();
var rb1Built = rb1.Build();
var rb2Built = rb2.Build();

通常在流畅的设计中会看到很多return this;。这导致了意外的行为。如果您创建了一个在调用Build()时执行的操作流水线，并且始终执行return new ResultBuilder(...);，则可以构建可靠的流利设计。

如果“构建器模式”从数据库值而不是参数输入构造对象，是否合适？

3 个答案: