Question

我正在为许多不同的客户构建Web服务，以连接到汽车零件数据库。这些部件具有多种特性。不同的客户需要不同的属性子集来“做他们的事情。”

所有客户至少需要一个ID，一个部件号和一个名称。有些可能需要价格，有些可能需要URL到图像等。下一个客户端可能会在几年后编写，并且需要不同的属性子集。我宁愿不发送超过他们需要的东西。

我一直在为每个要求构建单独的“PartDTO”属性子集，并将它们作为单独的Web服务方法提供，以返回相同的部件列表，但每个部件具有不同的属性。而不是为每个客户端构建这个并为DTO和方法提供逻辑名称，我想让客户端指定他们想要的方式。我正在返回JSON，所以我在考虑客户端向我传递一个JSON对象，列出了他们在结果集中所需的属性：

ret = {ImageUrl：true，RetailPrice：true，...}

首先，这有意义吗？

其次，我不想丢失的是返回IEnumerable＆lt;的好语法。 DTO＆gt;让JSON工具序列化它。我当然可以建立一个'JSON'字符串然后返回，但这看起来非常糟糕。

连连呢？ C＃'动态'？

Answer 1

这是Entity-Attribute-Value model的非常好的候选人。基本上你有一个ID，名称，价值表，你允许每个客户/方面存储他们想要的东西......然后当他们查询你返回他们的名字 - 值对并让他们随意使用它们。

PROS：超级灵活。适用于强模式增加大量复杂性与价值的情况。多个客户端的单个端点。

缺点：一般不喜欢的模式，很难有效地选择，也很难索引。但是，如果您只是存储并返回name-value的集合，那么它应该没问题。

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 for Part就像这样：

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
}

然后我为DictionaryAsDTO编写了一个JSON.NET转换器，它发出JSON-y对象属性而不是键值对。

Web服务基于返回IEnumerable并将其序列化的查询构建IEnumerable。

中提琴！

战略＆＃34;灵活的Web服务＆＃34;

2 个答案: