нафига такие сложности?
хотелось бы узнать, зачем вам это, не обязательно сильно детально.
не является ли это преждевременной оптимизацией или попытка сделать просто сложным? )
Вывод данных в эксель. Есть два вылизанных механизма, покрывающих все кейсы внешнего вида финального результата. Источником данных служит плоская серверная модель IEnumerable<IData>, с него получаемая или определенная на клиенте. Но описать класс и реализовать IData можно не всегда, есть несколько случаев с переменным количеством полей, собираемых из нескольких таких моделей. Под них есть зоопарк велосипедов, выводящих такие данные уникальным для каждого набора способом. Я хочу избавиться от этого зоопарка, создавая динамические модели на основе того же IEnumerable<IData>, и этот подход уже дал плоды, вскрыв несколько багов как в велосипедах, так и в данных на сервере. При правильном связывании данных, например, полезли дубли записей (косяки во внешних ключах) или новые данные, которых раньше видно не было (косяки в выводе). Пара велосипедов свелась к IEnumerable<IEnumerable<IData>>, но остальным требуется труъ динамика, набор жестких табличек не катит.
Ну а "просто" уже было сделано - к записи с фиксированными полями цеплялись наборы поле-значение, но это не спасло от говнокода. Да и отлаживать это сложнее, моск лучше анализирует коллекцию записей, чем коллекцию коллекций поле-значение.
hVosttпрежде чем идти в emit, я бы рекомендовал сначала решать задачу через Expression Tree, пока не упрёшься в затык по производительности.Посмотрел ET, показалось слишком мутным и сложным. Фабрика моделей на Emit уже заработала (CreateProperty это 80% ее кода), не вижу смысла переделывать.
