Comments 9
Все это замечательно, но как раз такой универсальный метод, который может выполнится разными способами (при обновлениях библиотек) может как раз подставить программиста и породит неожиданные ошибки.
Спасибо! возьму на заметку.
Чем именно лучше чем
T t = (T)System.ComponentModel.TypeDescriptor.GetConverter(typeof(T)).ConvertTo()
Ну, по первых, не все типы имеют TypeConverter.
Некоторые предоставляют только операторы преобразования (например: IntPtr или JToken из Json.NET).
Другие только методы Parse ToString (например: IPAddress).
Из некоторых типов просто не существует «валидных» преобразований, хотя они очевидны. Из int? в enum SystemColor?, где достаточно развернуть nullable типы и преобразовать содержимое.
И что бы не писать длинный switch\case по преобразуемым типам, проще вызвать один метод Convert, который сам найдет подходящий способ преобразования и вызовет его. Плюс мой вариант использует боксинг только в нескольких случаях.
Некоторые предоставляют только операторы преобразования (например: IntPtr или JToken из Json.NET).
Другие только методы Parse ToString (например: IPAddress).
Из некоторых типов просто не существует «валидных» преобразований, хотя они очевидны. Из int? в enum SystemColor?, где достаточно развернуть nullable типы и преобразовать содержимое.
И что бы не писать длинный switch\case по преобразуемым типам, проще вызвать один метод Convert, который сам найдет подходящий способ преобразования и вызовет его. Плюс мой вариант использует боксинг только в нескольких случаях.
Поскольку я пишу проект, который реализует схожие задачи, я бы посоветовал все же для очевидно-конвертируемых типов реализовать конверсионные варианты на этапе комиляции (механизмом Т4), т.к. использование reflection в глобальных масштабах, особенно когда нужно делать
Invoke() (например на TryParse()), слишком дорого.>использование reflection в глобальных масштабах
в методе Convert нет рефлексии. Ни капельки, только вызовы закешированных делегатов, которые по скорости сравнимы с виртуальными вызовами. Так что перфоманс будет достаточен для большинства задач.
Про ваш проект, я не понял для чего он.
в методе Convert нет рефлексии. Ни капельки, только вызовы закешированных делегатов, которые по скорости сравнимы с виртуальными вызовами. Так что перфоманс будет достаточен для большинства задач.
Про ваш проект, я не понял для чего он.
По-моему ценность библиотеки стремится к нулю. Она ничего не делает такого, чего нельзя сделать без этой библиотеки. Она существенно не уменьшает количество кода, который надо будет писать без неё. При необходимости для конкретных случаев пишется простенький хелпер, или класс, по крайне мере он будет всегда доступен в проекте и его можно поправить, доработать и улучшить. Ну и самое страшное. Предлагаемый хелпер может очень много какие типы конвертить, но не абсолютно все. Отсюда, его использование, это хождение по минному полю, знать поддерживаемые типы наизусть — не представляется возможным, каждый раз лазить на гитхаб в исходники, тоже не весёлое занятие. Читателя код, используемый этот конвертер будет поджидать недоумение, что ещё за конвертер? Что он может? Работает ли он как ожидается? А если способ конвертации изменится?
В общем, как часть собственного проекта — куда ни шло. Как самостоятельная библиотека — плохо.
В общем, как часть собственного проекта — куда ни шло. Как самостоятельная библиотека — плохо.
Sign up to leave a comment.
Преобразование типов значений в .NET