Добавление структуры к плоской модели данных вместо использования интерфейса?

Я пытаюсь интегрироваться с довольно устаревшим API (для работы, поэтому я не могу раскрыть фактическое именование, конечные точки и т. Д.), А их модели данных для конечных точек POST очень четко реализуют интерфейс, похожий на:

public interface IExternalData {
    int CallerId { get; set; }
    string CallerName { get; set; }
}

Когда я говорю, что они очень ясно реализовать интерфейс, я могу сделать это предположение, основываясь на том факте, что все их моделей данных содержат примерно 5 абсолютно одинаковых свойств. При этом ни одна из конечных точек не возвращает данные, поэтому все модели — это просто данные, которые, как ожидается, будут отправлены на соответствующие конечные точки.

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

public sealed class ApiPacket<T> {
    public int CallerId { get; set; }
    public string CallerName { get; set; }
    public T Data { get; set; }
    public Dictionary<string, object> KeyValuePairs {
        get {
            var dictionary = new Dictionary<string, object> {
                { "CallerId", CallerId },
                { "CallerName", CallerName}
            };
            string serializedData = JsonConvert.SerializeObject(Data);
            var data = JsonConvert.DeserializeObject<Dictionary<string, object>>(serializedData);
            foreach (string key in data.Keys)
                dictionary.Add(key, data[key]);

            return dictionary;
        }
    }
}

Единственное, от чего это меня действительно спасает, — это реализовать ~ 5 одинаковых свойств во всех моделях данных (их около 40 мне нужно создать). Так что, хотя это и избыточно, создание интерфейса и воздержание от усложнения ничего не мешает.

Вызывает ли моя структурированная реализация какие-либо опасения по поводу использования интерфейса, учитывая, что вариант использования предназначен только для публикации данных, а не для их получения?

• Мое обоснованное предположение — да, из-за ненужной сложности и того, что я должен пойти по маршруту интерфейса, но я хотел бы получить отзывы сообщества, прежде чем я приму трудное решение пойти в любом случае.

Вопросы и ответы из комментариев

@ iSR5 спросил:

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

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

Примечание: Чтобы уточнить, этих моделей еще нет в моем коде, и поэтому я здесь.

ОБНОВИТЬ

Спасибо за дополнительные пояснения. Поскольку вы работаете с веб-сервисом. Есть несколько вопросов, которые я задал себе по поводу вашего решения.

Если поставщик веб-API обновил свои конечные точки новыми ключами, нужно ли вам также добавить их в текущее решение? если да, то какой цели здесь служит словарь? что вы будете делать при каждом обновлении?

Текущее решение, похоже, обрабатывает ответ (или тело запроса), что происходит после этого? у вас есть такой обработчик для обработки сгенерированных данных в другом месте? если да, относится ли этот обработчик к этому классу или он также используется для других объектов?

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

Вот некоторые вещи, о которых я должен упомянуть (только на заметку):

• с использованием object добавит больше упаковки и распаковки, поэтому вам всегда нужно приводить значения к их соответствующим типам.
• с использованием JsonConvert всегда буду добавлять Json.NET как требование к этому решению.

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

Старый ответ

Хотя ваш подход более удобен в обслуживании, гибок, а также снизит сложность кода, он также добавит больше времени и усилий самому проекту, поскольку за рефакторинг кода всегда есть скрытые сборы!

Пытаясь применить новое изменение дизайна к протестированному и выпущенному коду, вы фактически добавляете дополнительные средства разработки, тестирования и сопровождения к новому дизайну, а также вносите новые ошибки.

Так что дело не только в том, что если кто-то будет работать над этим, узнает об этом изменении или нет! Это также связано с затратами времени, усилий и управления.

Что я думаю и что бы делал на вашем месте: если рефакторинг необходим, я бы постарался избегать добавления новых классов и использовать то, что .NET предложения — например, использование IHttpActionResult или HttpResponseMessage классы вместо этого. Это было бы легче поддерживать, и это было бы легко понять!

Если нужно сделать слишком много работы, тогда DelegatingHandler может быть решением. Это полезный обработчик, поскольку он перехватывает каждый запрос / ответ и делегирует их другому обработчику. Итак, вы можете создать обработчик для обработки всех запросов / ответов без изменения какого-либо контроллера.