Подходит ли, если Builder Pattern строит объект из значения базы данных вместо ввода параметра - PullRequest
0 голосов
/ 24 февраля 2019

Планирует использовать шаблон строителя, но я не уверен, что это правильный способ использования или нет.здесь: 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();

Ответы [ 3 ]

0 голосов
/ 24 февраля 2019

Не уверен, что вы можете «построить» Дилера, если это не магазин.Вместо этого используйте Dealer в качестве объекта Director, который вызывает собственный метод Construct, который принимает объект Builder в качестве параметра.

Для шаблона построения требуется класс Director, состоящий из 1 или более классов Builder.Классы Builder создают детали.

Вы можете создать абстрактный класс Builder и иметь бетонированных конструкторов для деталей для мотоциклов, автомобилей или кораблей.Эти компоновщики предоставляют метод для возврата размещаемого продукта, являющегося частями в данном случае.

0 голосов
/ 25 февраля 2019

Следует учитывать, являются ли шаги PrepareParts().PrepareDealer() обязательными или нет, и могут ли они быть пропущены или нет.И, в этом отношении, важен ли порядок операций.

Если все шаги являются обязательными, и если вы должны сделать это по порядку, то сборщик не является отличным способом.

Следующее, что вы должны рассмотреть, это то, хотите ли вы сменить поставщика данных для ваших шагов.Тогда вам понадобится какая-то инъекция зависимостей в ваш конструктор.Возможно, вы захотите получить источник из базы данных, диска или веб-службы, например.

Наконец, вы должны рассмотреть, что должен делать этот код:

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

Часто вы видите много return this; в свободном дизайне.Это приводит к неожиданному поведению.Если вы создаете конвейер действий, которые выполняются при вызове Build(), и вы всегда делаете return new ResultBuilder(...);, тогда вы можете создать твердый плавный дизайн.

0 голосов
/ 24 февраля 2019

Основная проблема, с которой строитель заполняет объект таким образом, заключается в том, что ваш строитель только сможет создавать вещи таким образом.

Например, в следующем месяце вы можете найтичто вам нужно построить один из этих объектов с аналогичными данными, полученными из других источников.

Было бы более гибким сохранить разделение интересов (или «принцип единой ответственности»: S из SOLID ), сохраняя конструктор в качестве компоновщика и используя другой класс для координации выборки данных и передачи их компоновщику.

Это "неправильный дизайн" чтобы сделать это так, как вы описали?Проектные решения очень субъективны и должны основываться на известных и ожидаемых требованиях на тот момент.Например, принципы проектирования против выполнения того, что я предложил: YAGNI и Правило трех .

Другими словами, вы должнысбалансировать увеличение гибкости с увеличением количества кода.

...