генерирую в сборке по некоторому описанию анемичные модели (для передачи через какой-нибудь wcf/webservice)
и хочу генерировать во второй сборке что-то типа загрузчика данных в модели для стороны сервиса (правила тоже есть в описании)

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

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

спасибо

Здравствуйте, Аноним, Вы писали:

А>генерирую в сборке по некоторому описанию анемичные модели (для передачи через какой-нибудь wcf/webservice)
А>и хочу генерировать во второй сборке что-то типа загрузчика данных в модели для стороны сервиса (правила тоже есть в описании)

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

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

А>спасибо

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>генерирую в сборке по некоторому описанию анемичные модели (для передачи через какой-нибудь wcf/webservice)
А>>и хочу генерировать во второй сборке что-то типа загрузчика данных в модели для стороны сервиса (правила тоже есть в описании)

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

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

А>>спасибо

А>Помечать атрибутами — логичное и уже используемое стандартными макросами решение. В принципе, еще можно первым макросом генерировать файлик, и читать его вторым. Можно даже сериализацию попробовать.

Меня смущает несколько пунктов:
1. то, что в этот атрибут придется запихивать достаточно большой объем данных в виде строки
про идею с файлом спасибо, попробую туда имя файла присунуть
2. атрибут придется заводить в третьей сборке, видимой и макросами и моделью (или нет?)

Здравствуйте, Аноним, Вы писали:

А>2. атрибут придется заводить в третьей сборке, видимой и макросами и моделью (или нет?)

Видимо, да. Ведь макросы должны его читать.

Здравствуйте, catbert, Вы писали:

C>Видимо, да. Ведь макросы должны его читать.

Совсем не обязательно иметь рантайм тип для чтения атрибута — этот тип нужен только для материализации экземпляра атрибута.
До самих значений можно добраться через CustomAttributeData.

Здравствуйте, Аноним, Вы писали:

А>1. то, что в этот атрибут придется запихивать достаточно большой объем данных в виде строки
А> про идею с файлом спасибо, попробую туда имя файла присунуть

С другой стороны, данные можно в массивом byte запихнуть

А>2. атрибут придется заводить в третьей сборке, видимой и макросами и моделью (или нет?)

Не обязательнов третьей, атрибуты можно читать не имея "на руках" статического типа атрибута, см CustomAttributeData.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>1. то, что в этот атрибут придется запихивать достаточно большой объем данных в виде строки
А>> про идею с файлом спасибо, попробую туда имя файла присунуть

H>С другой стороны, данные можно в массивом byte запихнуть
жестячок

А>>2. атрибут придется заводить в третьей сборке, видимой и макросами и моделью (или нет?)

H>Не обязательнов третьей, атрибуты можно читать не имея "на руках" статического типа атрибута, см CustomAttributeData.
да, пожалуй, на этом и остановлюсь

Здравствуйте, Аноним, Вы писали:

А>вижу два подхода — либо использовать это же самое описание (файл),

Что за файл? Какой формат?

А>либо как-то помечать модели
А>первый вариант мне кажется несколько стремным

Нормальный вариант. Можно реализовать чтение в отдельной библиотеке и использовать ее при компиляции обоих сборок (из макросов).

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

А>- заново парсить файл,

Это не проблема, если парсинг идет быстро.

А>искать в нем описания,

Какой характер описаний? На основании чего производится поиск?

А>потом искать типы сгенеренных моделей. как-то не нравится

А зачем их искать? Если нужно сослаться на тип, то искать его не обязательно. Можно же смылаться по имени.

В общем, маловато как-то информации.

Хорошо бы продемонстрировать формат фала с описанием, примеры генерируемого по нему кода и т.п. Чем больше деталей (в разумных пределах), тем лучше.