Не могу согласиться
У меня как-то получилось так, что куча импортов из файлов работает в конечном счете с той или иной таблицей (пусть и временной), под такой случай получилось несколько базовых классов:
- абстрактный импорт из файла на стороне клиента: по принципу работы RunBase.prompt() умеет переключаться на клиента для считывания данных в Map, который затем затягивается на сервер для дальнейшей обработки;
- на базе него абстрактный импорт полей записи; класс-наследник должен определиться с тем, в какую таблицу какие поля из каких номеров "колонок" считывать, какие поля обязательны к заполнению (если они окажутся пустыми, импорт на стороне клиента завершится), а также (та-да!) переопределить метод, считывающий из указанной колонки значение указанного базового типа. Класс, в свою очередь, через Dict-классы определяет, как какое поле считывать, до скольки символов обрезать строки, выполняет все сопутствующие проверки, кэширует нужные метаданные для ускорения и т.п.
- на базе него абстрактный класс импорта записей: тут добавляется кое-какая логика по пред- и постобработке записей, корректировке считанных значений полей (скажем, валютные суммы могут округляться с выводом соотв. предупреждений), сохранении считанных записей в RecordSortedList для выявления дубликатов и/или обработки в нужном порядке.
Плюс к этому еще есть класс-наследник, реализующий на базе этого всего импорт из файлов Excel. Так вот, обычно импорт в ту или иную конкретную таблицу либо реализует целиком всю остальную логику, т.е. фактически указывает, что в такую-то таблицу надо считать такие-то поля, а в остальном просто обрабатывает считанные табличные записи, либо разбивается на два класса: некий, опять же, абстрактный импорт для той или иной таблицы (обычно это строки журналов) и на базе него - уже некий обработчик, скажем, для того или иного типа журналов.
За счет этого:
- оптимизируется клиент-серверное взаимодействие, вся основная работа, все "тяжелые" проверки производятся на сервере;
- легко и просто ловится "конец файла" (скажем, в Excel-файлах пользователи любят протягивать значения ряда колонок до самого низа, хотя импортят 10-20 строк, а так нет значений обязательных полей - значит, пора закругляться);
- в каждом новом импорте можно использовать кучу готового проверенного кода и абстрагироваться от того, откуда или как считываются данные. К примеру, импорт строк журналов ГК из Excel изначально работал через ADO, потом меня забодало бороться с "особенностями" последнего, и я его переписал на SysExcel, а того, в свою очередь, с COM на .NET - все остальные импорты, работающие со строками журналов ГК, при этом никак затронуты не были, но начали работать "на новых рельсах".
Но это все, конечно, - из разряда импортов, используемых каждый день; однако, даже в тупых джобах, лопатящих контейнеры, полученные из AsciiIo, хочется абстрагироваться от таких вот заморочек, хочется не придумывать в ндцатый раз, как корректно считать из файла значение типа enum и т.п.