Оптимизация перевода данных

Question

Наш бизнес занимается домами, и за прошедшие годы мы создали несколько бизнес-объектов для их представления. Мы также получаем много данных из внешних источников и отправляем данные внешним потребителям. Каждый из них представляет дом по-своему, и мы тратим много времени и энергии на перевод одного формата в другой. Я ищу некоторые общие закономерности или лучшие практики, как справиться с этой ситуацией. Как мне написать универсальный переводчик данных, который будет гибким, расширяемым и быстрым.

Общая информация: Дом обычно имеет 30-40 атрибутов, таких как размер, количество спален, тип крыши, строительный материал, сайдинг и т. Д. Они обычно представлены в виде пар ключ / значение. Типичная проблема перевода заключается в том, что один поставщик будет представлять количество спален в виде одной пары ключ / значение: NumBedrooms = 3, в то время как другой поставщик будет иметь пару ключ / значение для спальни: спальня = главная, спальня = маленькая, спальня = маленький. В переводе нет ничего особенно сложного, но мы тратим много времени и сил на написание и тестирование переводов. Как я могу оптимизировать это?

Спасибо

(Моя среда .Net)

Answer 1

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

Хорошей стратегией реализации является экстернализация преобразования, если вы можете. Если вы можете получить свои входные и выходные данные в XML-документах, то вы можете написать XSLT-преобразования между вашими внутренними и внешними представлениями. Цель состоит в том, чтобы иметь возможность настроить конвейер преобразований из входного XML-документа во внутреннее представление. Если все представлено в XML и использует общий протокол (скажем ... хмм ... HTTP), тогда процесс можно контролировать с помощью конфигурации. Кстати, это, по сути, шаблон проектирования Трубы и фильтры .

Взгляните на каналы Yahoo , Apache Cocoon , XML pipe и NetKernel для вдохновения.

Answer 2

Мой работодатель еще в 90-х столкнулся с этой проблемой. У нас был стандартный формат, в который мы конвертировали данные клиентов в и из, как предлагает Д.Шоули.

Я пошел дальше и разработал простой язык описания формата; мы описали наш стандартный формат на этом языке, а затем, для нового набора данных, мы также напишем его формат. Затем программа получит оба описания и преобразует данные из одного формата в другой с автоматическим преобразованием типов, проверками безопасности и т. Д. (Это пригодилось и для некоторых других операций, а не только для этих начальных / конечных преобразований.) 1003 *

Подробности, вероятно, не помогут вам - скорее всего, вы имеете дело с совершенно разными видами данных. Вы, вероятно, можете извлечь выгоду из общего принципа, хотя. «Язык определения данных» не обязательно должен быть модным с парсером и сканером; Вы можете определить это непосредственно с помощью структуры данных в IronPython, скажем.