Стратегии для «Гибкого Webservice»

Question

Я создаю веб-сервисы для разных клиентов для подключения к базе данных автомобильных деталей. Эти части имеют широкий спектр свойств. Различные клиенты будут нуждаться в разных поднаборах свойств, чтобы «делать свою работу».

Все клиенты должны иметь хотя бы ID, номер детали и имя. Некоторым могут потребоваться цены, некоторые могут нуждаться в URL-адресах для изображений и т. Д. И т. Д. Следующий клиент может быть написан через несколько лет и требует еще одного подмножества свойств. Я бы предпочел не отправлять больше, чем нужно.

Я создавал отдельный «PartDTO's» с подмножествами свойств для каждого из этих требований и обслуживал их как отдельные методы webservice, чтобы возвращать один и тот же список частей, но с разными свойствами для каждого из них. Вместо того, чтобы создавать это для каждого клиента и придумывать логические имена для DTO и методов, я хотел бы, чтобы клиент указал, что они хотят. Я возвращаюсь JSON, так что я думал о клиенте передавая мне объект JSON список свойств, которые они хотят в итоге-набор:

в отставке = {ImageUrl: истинное, RetailPrice: правда, ...}

Прежде всего, это имеет смысл?

Во-вторых, то, что я не хочу потерять, - это хороший синтаксис для возврата IEnumerable < DTO> и пусть инструменты JSON сериализуют его. Я мог бы, конечно, создать строку «JSON» и вернуть ее, но это кажется довольно kludgey.

Предложения? C# 'dynamic'?

Answer 1

Это очень хороший кандидат на Entity-Attribute-Value model. В основном у вас есть таблица идентификаторов, имя, значение, и вы позволяете каждому клиенту/фасету хранить то, что они хотят ... Затем, когда они запрашивают, вы возвращаете свои пары значений имени и позволяете им использовать их по своему усмотрению.

PROS: супер эластичный. Хорошо для ситуаций, когда сильная схема добавляет массу сложности и ценности. Единая конечная точка для нескольких клиентов.

CONS: В целом не нравится шаблон, очень трудно выбрать из эффективного, а также трудно индексировать. Однако, если все, что вы делаете, это хранить и возвращать коллекции именных значений, это должно быть хорошо.

Answer 2

В итоге я перешел на словарь-маршрут. Я определил базовый класс:

public abstract DictionaryAsDTO<T> : IReadOnlyDictionary<string, object> 
{ 
    protected DictionaryAsDTO(T t, string listOfProperties) 
    { 
     // Populate an internal dictionary with subset of t's props based on string 
    } 
} 

Тогда DTO для части так:

public PartDTO : DictionaryAsDTO<Part> 
{ 
    public PartDTO(Part p, string listOfProperties) : base(p, listOfProperties) {} 

    // Override method to populate base's dictionary with Part properties based on 
    // listOfProperties 
} 

Тогда я написал Json.NET конвертер для DictionaryAsDTO, излучающий JSON-у объекта-свойства вместо кнопочная -значение пары.

Веб-сервис создает IEnumerable на основе запросов, которые возвращают IEnumerable и сериализуют их.

Виола!