代码之家 › 专栏 › 技术社区 › dsi

如果生成器模式使用数据库值而不是参数输入来构造对象,是否合适

facade fluent builder design-patterns c#

0

dsi · 技术社区 · 7 年前

计划使用builder模式,但是,我不确定它的使用方法是否正确。在这里, 1)从数据库或api中提取数据并构造对象2)post到api

所以,看起来,这个套件到生成器的设计模式如下:

我并没有看到使用builder模式从数据库读取数据来构造对象的示例。当从数据库或API检索到的数据或LSE中压缩对象时,它是合适的模式吗?它的设计是错误的? 例子:

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();

0 回复 | 直到 7 年前

1

Richardissimo 7 年前

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

例如,下个月,您可能会发现需要使用来自其他地方的类似数据来构建其中一个对象。

保持 separation of concerns (或) “单一责任原则” S来自 SOLID )通过将生成器保持为生成器,并使用不同的类来协调获取数据并将其传递给生成器。

它是 “错误的设计” 按你说的做?设计决策是非常主观的,应该基于当时已知和预期的需求。例如,设计原则反对按照我的建议做 YAGNI 和 Rule of Three .

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

2

1

CyrilDex 7 年前

不确定你可以“建立”一个经销商,除非这是一个商店。相反,让dealer作为director对象,它调用自己的构造方法,接受builder对象作为参数。

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

你可以制作一个抽象的建筑类,并有摩托车、汽车或船体的具体建筑商。这些构建器提供了一个方法来返回它们所承载的产品,这些产品是本实例中的部件。

3

0

Enigmativity 7 年前

你应该考虑一下 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(...); 然后,你可以建立一个坚实流畅的设计。