Шаблон проектирования для возврата объекта структуры данных, который не всегда может быть заполнен полностью?

Question

У меня есть ситуация, когда я запрашиваю веб-сервис RESTful (использующий .NET), который возвращает данные в виде XML.Я написал функции-оболочки вокруг API, чтобы вместо возврата исходного XML-кода я возвращал полные .NET-объекты, которые отражают структуру XML.XML может быть довольно сложным, поэтому эти объекты могут быть довольно большими и сильно вложенными (т. Е. Содержать коллекции, которые, в свою очередь, могут содержать другие коллекции и т. Д.).

REST API имеет возможность вернуть полный результат илиосновной результат.Базовый результат возвращает небольшое подмножество данных, которое делает полный результат.В настоящее время я имею дело с двумя типами ответов, возвращая один и тот же объект .NET для обоих типов запросов, но в базовом запросе некоторые свойства не заполняются.Это лучше всего видно на (очень упрощенном) примере кода:

public class PersonResponse
{
    public string Name { get; set; }
    public string Age { get; set; }
    public IList<HistoryDetails> LifeHistory { get; set; }
}

public class PersonRequest
{
    public PersonResponse GetBasicResponse()
    {
        return new PersonResponse() 
        { 
            Name = "John Doe", 
            Age = "50", 
            LifeHistory = null 
        };
    }

    public PersonResponse GetFullResponse()
    {
        return new PersonResponse() 
        { 
            Name = "John Doe", 
            Age = "50", 
            LifeHistory = PopulateHistoryUsingExpensiveXmlParsing()
        };
    }
}

Как вы можете видеть, класс PersonRequest имеет два метода, которые оба возвращают объект PersonResponse.Однако метод GetBasicResponse является «облегченной» версией - он не заполняет все свойства (в данном примере он не заполняет коллекцию LifeHistory, поскольку это «дорогая» операция).Обратите внимание, что это очень упрощенная версия того, что на самом деле происходит.

Однако, для меня это имеет определенный запах (поскольку вызывающий метод GetBasicResponse должен понимать, какие свойстване будет заселяться).

Я думал, что более методология ООП будет иметь два объекта PersonResponse - объект BasicPersonResponse и FullPersonResponse, причем последний наследуется от первого.Что-то вроде:

public class BasicPersonResponse
{
    public string Name { get; set; }
    public string Age { get; set; }
}

public class FullPersonResponse : BasicPersonResponse
{
    public IList<object> LifeHistory { get; set; }
}

public class PersonRequest
{
    public BasicPersonResponse GetBasicResponse()
    {
        return new FullPersonResponse()
        {
            // ...
        };
    }

    public FullPersonResponse GetFullResponse()
    {
        return new FullPersonResponse()
        {
            // ...
        };
    }
}

Однако, это все еще не совсем "чувствуется" правильно - по причинам, в которых я не совсем уверен!

Есть ли лучший шаблон проектирования, чтобы иметь дело сэта ситуация?Я чувствую, что мне не хватает чего-то более элегантного?Спасибо!

Answer 1

Я думаю, вы описали шаблон прокси.Подробности см. Здесь: Иллюстрированные шаблоны проектирования GOF на C #

Answer 2

У меня также есть неприятное чувство об использовании наследования для добавления «дополнительных данных» вместо добавления / изменения поведения. Основным преимуществом этого является то, что ваши методы могут указывать, какой уровень детализации они требуют в своих типах аргументов.

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