Что такое хороший шаблон проектирования для реализации инструмента импорта динамических данных?
Мы планируем создать инструмент для динамического импорта данных. Собирая информацию на одном конце в указанном формате (access, excel, csv) и загружая ее в веб-сервис.
Ситуация такова, что мы не знаем имен полей экспорта, поэтому приложение должно иметь возможность видеть определение wsdl и сопоставлять действительные записи на другом конце.
В разделе импорта мы можем определить большинство полей, но обычно они имеют несколько пользовательских. Что я не вижу проблем с этим.
Мне просто интересно, есть ли шаблон проектирования, который подойдет для этого типа приложений или поможет в его разработке.
5 ответов
Я не уверен, в чем сложность вашего приложения, поэтому я просто приведу пример того, как я использовал шаблоны для импорта данных различных форматов. Я создал фабрику, которая принимает формат файла в качестве аргумента и возвращает анализатор для определенного формата файла. Тогда я использую шаблон строителя. Синтаксический анализатор снабжен компоновщиком, который анализатор вызывает во время синтаксического анализа файла для создания требуемых объектов данных в приложении.
// In this example file format describes a house (complex data object)
AbstractReader reader = factory.createReader("name of file format");
AbstractBuilder builder = new HouseBuilder(list_of_houses);
reader.import(text_stream, builder);
// now the list_of_houses should contain an extra house
// as defined in the text_stream
Я бы сказал "Шаблон адаптера", поскольку вы "адаптируете" данные из файла к объекту, как это делает SqlDataDataAdapter из таблицы Sql в DataTable.
есть разные адаптеры для каждого типа / формата файла? пример SqlDataAdptor, MySqlDataAdapter, они обрабатывают одни и те же команды, но разные источники данных, чтобы получить один и тот же вывод DataTable
НТН
скелет
Вероятно, Bridge может подойти, так как вам приходится иметь дело с различными форматами файлов. И Фасад, чтобы упростить использование. Обращайтесь с моим ответом осторожно, я просто изучаю шаблоны проектирования:)
Наша ситуация такова, что нам нужно импортировать параметрические фигуры из файлов конкурентов. Расположение их экрана и полей данных схожи, но достаточно различны, так что происходит процесс преобразования. Кроме того, у нас более полудюжины конкурентов, и обслуживание будет кошмаром, если будет сделано только через код. Поскольку большинство из них используют таблицы для хранения своих параметров для своих фигур, мы написали коллекцию объектов общего назначения для преобразования X в Y.
В моем приложении CAD/CAM импорт файла является командой. Однако магия преобразования выполняется набором правил посредством следующих шагов.
- Импортируйте данные в таблицу. Имена полей также вводятся в зависимости от формата.
- Мы передаем таблицу в RuleSet. Я объясню структуру набора правил через минуту.
- Набор правил преобразует данные в новый набор объектов (или таблиц), которые мы извлекаем
- Мы передаем результат остальной части программного обеспечения.
Набор правил состоит из набора правил. Правило может содержать другое правило. У правила есть СОСТОЯНИЕ, которое оно проверяет, и ТАБЛИЦА КАРТ.
MAP TABLE отображает входящее поле с полем (или свойством) в результате. Может быть одно отображение или множество. Отображение не должно включать в себя просто вставка входного значения в поле вывода. У нас также есть синтаксис для вычисления и объединения строк.
Этот синтаксис также используется в условии и может включать в себя несколько файлов, таких как ([INFIELD1] & "-" & [INFIELD2])="AB" или [DIM1] + [DIM2] > 10. Все, что в скобках заменяется на входящее поле.
Правила могут содержать другие правила. Это работает так, что для сопоставления подчиненного правила должны применяться как его условия, так и условия его родителя (или родителей). Если у sub Rule есть отображение, которое конфликтует с отображением родителя, тогда применяется SubRule Mapping.
Если два правила на одном и том же уровне имеют условие, которое является истинным и имеют конфликтующее отображение, то правило с применимым отображением будет иметь правило с более высоким индексом (или более низким в списке, если вы просматриваете древовидное представление).
Вложенные правила эквивалентны AND, в то время как правила на том же уровне эквивалентны OR.
Результатом является таблица сопоставления, которая применяется к входящим данным, чтобы преобразовать их в нужный вывод.
Это дружелюбно для отображения в пользовательском интерфейсе. А именно, древовидная структура, показывающая иерархию правил, и боковая панель, отображающая таблицу сопоставления и условия правила. Не менее важно то, что вы можете создавать мастеров, которые автоматизируют общие структуры правил.
Вам, вероятно, также понадобятся шаблоны Abstract Factory и Command.
Если данные не соответствуют формату ввода, вам, вероятно, потребуется как-то преобразовать его. Вот тут и появляется шаблон команды. Поскольку форматы являются динамическими, вам нужно будет основывать команды, которые вы генерируете, на входе. Вот где абстрактная фабрика полезна.