Разделение рендеринга PDF в сборку многократного использования / использование разных стратегий рендеринга - PullRequest
0 голосов
/ 07 июня 2018

У нас есть два приложения: настольный клиент и серверная часть mvc.Оба приложения имеют функции печати.И совершенно очевидно, что мы повторяем это.Позвольте мне объяснить это.Процедура выглядит следующим образом:

  1. Пользователь вводит свой идентификатор / отправляет свои данные в конечную точку mvc;
  2. Мы проверяем базу данных, если все необходимые данные верны;
  3. Мы создаем объект viewmodel (mvc) / dto (desktop);
  4. В качестве требования необходимо напечатать два типа документов;
  5. Затем мы делаем идентичные вызовы для рендеринга PDF.API (мы используем PdfSharp), создающий два документа.

Я думаю, было бы лучше, если бы у нас была эта pdf-составляющая логика в отдельной сборке.Тогда это может быть многоразовым.Проблема в том, что в документах используются немного другие свойства (данные).В качестве решения мы можем использовать один общий dto со всеми необходимыми свойствами:

public IEnumerable<string> Render(DocumentDto document) {
    // ioc
    foreach(var strategy in this.strategies) {
        if(strategy.CanRender(document)) {
            yield strategy.Render(document);
        }
    }
}

Мы также можем внедрить объект DbContext в наши стратегии.И каждая стратегия будет запрашивать нужные свойства самостоятельно:

public class StrategyA {
    // I'll omit ctor here
    private DbContext db;
    public string Render() {
        // make db calls
        // render the document
    }
}

Но я тоже не думаю, что это хорошее решение, так как оно требует зависимости db.

Можем ли мы спроектировать егочтобы каждая стратегия использовала только свой набор свойств?

...