Comments 6
Статья хорошая, позволю себе немного дополнить
1. Обязательно кешируйте полученные объекты для каждого типа. Вроде в комментариях были намеки на кеширование, но в явном виде я его пропустил.
2. Будьте аккуратны с местом хранения. Хранить можно в динамической сборке, или выгружать сборку со всеми необходимыми типами на диск. Если выгружаете на диск — придется заморачиваться с версионированием, деплоем, подключением. Если храните в динамике — будьте осторожнее при работе с IIS. У меня был баг, когда новая версия динамической библиотеки не подхватывалась сервером до перезагрузки сервера.
3. При написании подобного рода вещей не очень удобно дебажить программу. Сформированный IL приходится смотреть через ildasm. Если пошли этим путем — лучше заранее подготовить тесты.
В целом, мы в свое время на Expression Trees перешли. Дебажить и кешировать проще. Еще один интересный вариант: Roslyn, написать собственный Extension будет довольно просто, и результирующий код будет виден сразу. Сам не пробовал, но в теории плюсы есть.
1. Обязательно кешируйте полученные объекты для каждого типа. Вроде в комментариях были намеки на кеширование, но в явном виде я его пропустил.
2. Будьте аккуратны с местом хранения. Хранить можно в динамической сборке, или выгружать сборку со всеми необходимыми типами на диск. Если выгружаете на диск — придется заморачиваться с версионированием, деплоем, подключением. Если храните в динамике — будьте осторожнее при работе с IIS. У меня был баг, когда новая версия динамической библиотеки не подхватывалась сервером до перезагрузки сервера.
3. При написании подобного рода вещей не очень удобно дебажить программу. Сформированный IL приходится смотреть через ildasm. Если пошли этим путем — лучше заранее подготовить тесты.
В целом, мы в свое время на Expression Trees перешли. Дебажить и кешировать проще. Еще один интересный вариант: Roslyn, написать собственный Extension будет довольно просто, и результирующий код будет виден сразу. Сам не пробовал, но в теории плюсы есть.
Благодарю!
1. Момент с кэшированием я намеренно опустил при написании статьи, т.к. считаю что эта задача ложится полностью на самого разработчика. Если в исходной задаче требуется кешировать сформированных экземпляры типов — это должно быть реализовано уже непосрественно самим разработчиком целевого решения. Касательно повторной генерации ранее объявленных типов — в самой первой перегрузке метода GenerateType(object) есть проверка на наличие метаданных типа в сборке. Если он ранее уже был объявлен, инициализируем новый экземпляр типа и сохраняем в сборке с помощью typeBuider.CreateType(), иначе выполняем всю процедуру генерации метаданных типа.
2. Для решения задачи, описанной в статье, было достаточно использовать динамическую сборку, хранимую в памяти. Для Flex-сервера, на котором тестировалось данное решение, были важны только метаданные самих типов, информация о сборке при отправке на сервер не учитывалась. Нужно было лишь позаботиться о псевдонимах типов и их членов, что мы и сделали с помощью маппинга.
3. Согласен с этим моментом. Но считаю что для данной статьи он не критичен. Я упоминал, что тема рефлексии и IL это уже тема для отдельной, полноценной статьи, здесь же она затронута лишь на уровне самого базового понимания концепции.
На счёт Roslyn — так же соглашусь. Но хочу заметить, что статья изначально была рассчитана на разработчиков младшего и среднего звена, расширения компилятора C# это, на мой взгляд, решение более продвинутого уровня (хотя и тоже вполне решение задачи и вполне имеет место быть).
1. Момент с кэшированием я намеренно опустил при написании статьи, т.к. считаю что эта задача ложится полностью на самого разработчика. Если в исходной задаче требуется кешировать сформированных экземпляры типов — это должно быть реализовано уже непосрественно самим разработчиком целевого решения. Касательно повторной генерации ранее объявленных типов — в самой первой перегрузке метода GenerateType(object) есть проверка на наличие метаданных типа в сборке. Если он ранее уже был объявлен, инициализируем новый экземпляр типа и сохраняем в сборке с помощью typeBuider.CreateType(), иначе выполняем всю процедуру генерации метаданных типа.
2. Для решения задачи, описанной в статье, было достаточно использовать динамическую сборку, хранимую в памяти. Для Flex-сервера, на котором тестировалось данное решение, были важны только метаданные самих типов, информация о сборке при отправке на сервер не учитывалась. Нужно было лишь позаботиться о псевдонимах типов и их членов, что мы и сделали с помощью маппинга.
3. Согласен с этим моментом. Но считаю что для данной статьи он не критичен. Я упоминал, что тема рефлексии и IL это уже тема для отдельной, полноценной статьи, здесь же она затронута лишь на уровне самого базового понимания концепции.
На счёт Roslyn — так же соглашусь. Но хочу заметить, что статья изначально была рассчитана на разработчиков младшего и среднего звена, расширения компилятора C# это, на мой взгляд, решение более продвинутого уровня (хотя и тоже вполне решение задачи и вполне имеет место быть).
Вместо FluorineFX можно использовать мою реализацию сериализатора AMF и сервера, работающую со стандартными DataContractAttribute/DataMemberAttribute ;)
Sign up to leave a comment.
Маппинг в C# на примере сериализатора для AMF