У нас с другом была такая шутка. Что есть человек, который настолько любит ассемблер, что куда бы он ни устроился и на каком бы языке не писал, пишет код с ассемблерными вставочками :) И этим бесит коллег, потому что никто эти вставки не понимает)
Сейчас занимался сравнением производительности и для меня это тоже стало открытием, статей по поводу внутренней реализации не нашёл, остаётся только посмотреть, что внутри у этих контролов
Кешируется в инстансе конвертера. Объекты Binding и CalcConverter создадутся по одному разу для каждого вычисляемого биндинга, один раз скомпилируется выражение для каждого вычисляемого биндинга. И всё) А вы знаете как работают биндинги в списковых контролах типа DataGrid или ListView? У Вас и обычные биндинги тоже создадутся ровно столько раз, сколько они упомянуты в разметке, независимо от числа элементов.
Великолепная статья! Как раз на этой неделе искал источники с описанием реализации переходников. Скажите, пользовались ли Вы какими-то источниками кроме анализа самого исходного кода? И если не секрет, какими? Я перелопатил целую кучу книг затрагивающих эти темы, в т.ч. SSCLI 2.0 INTERNALS, и не нашёл не то что упоминания структуры FixupPrecode, а даже четкого деления переходников на типы. Везде тема переходников затрагивается вскользь и ограничивается общими словами. А у Вас всё так ёмко изложено, со схемой связывания SLOT+MethodDesc+Precode и даже с указанием выводов «Указанный переходник был разработан с целью оптимизации использования памяти.». Где же об этом можно найти информацию?
В точку про HR-менеджеров! Как же надоело, что они звонят и не могут ответить на вопросы о том, что собственно за проект? Так и хочу им сказать: люди! Вы не рабочего нанимаете, яму копать! Нам недостаточно знать, что у вас есть яма! Нам нужны подробности!
Или у меня второй вариант — давайте так. HR не знает про работу, я не знаю про себя. «Почему вы уволились с прошлого места работы?» -«Вы знаете, я сейчас не могу вам сказать, мне надо свериться, пригласите меня на собеседование и там всё обсудим»)))
Да, скоро постараюсь выложить nuget пакет для .NET 4.0. Эта версия будет отличаться от версии для .NET 4.5 только отсутствием свойства ValidatesOnNotifyDataErrors, поскольку его добавили только в версии 4.5
я не говорю о том, что в xaml следует переносить любую хоть немного сложную логику: операции с массивами, linq выражения, вызов функций из своих классов и т.д. но я считаю что простые выражения, которыми активно можно пользоваться в интерфейсе, могут и должны быть очевидным образом прописаны в xaml.
да, замерял. Конвертер парсит строку 1 раз, по строке создается делегат, который ничего уже не парсит, а выглядит как функция, принимающая на вход source property и реализующая логику распарсенного выражения. Замер скорости ведется для всех биндингов из примера к библиотеке, которая лежит на github рядом с ним.
Стоящее замечание, спасибо. То есть если я вас правильно понял решарпер в случае переименования свойства во вьюмодели изменит в xaml все биндинги к нему. А как он определит в design time что вьюха относится к определенной вьюмодели? Только по name convention?
Принципиально отличается двумя пунктами.
Первое, quick converter судя по всему не умеет вынимать из выражения path имена source property. Поэтому они используют простые стандартные шаблоны $p которые без труда можно найти. Из за этого вам приходится лепить эти конструкции с шаблонами а потом еще биндинги отдельно указывать, согласитесь выглядит не очень юзабельно. Я бы не хотел этим загромождать xaml, для меня, как автора либы, вопрос удобства использования стоял принципиально. В моем биндинге в path вы можете писать какие угодно свойства и вложенные в несколько других вью моделей и понескольку раз одно и тоже, словом как вам удобно вытащить данные. А вот свойства типа p0 p1 извините, выглядят как костыль или временное решение
Второе. В quick converter необходимо вручную забивать выражение для обратного биндинга из dependency property к source property. У меня, как описание в статье выше, выражение представляется в виде функции для которой автоматически ищется обратная и новое выражение служит для обратного связывания
Насчет плюсов quick converter: я считаю что уже Linq выражения это уж точно не обязанность представления, это довольно далеко от представления и это должно быть во вьюмодели, кстати это тот случай о котором писал onikiuchika, писать tostring с целью поменять формат выода в path тоже не следует, для этого есть прекрасное свойство string format в стандартном binding.
С учетом этого я не вижу сильных преимуществ quick converter перед моим решением.
Словом, мое решение требует от вас меньше кода, а возможностей, которыми вы реально будете пользоваться, дает больше
Добавить поддержку конвертера не составляет труда, единственной причиной ее отсутствия было отсутствие примера который бы показывал необходимость в этом. О различиях между библиотеками напишу в ответе на ваш второй комментарий, спасибо.
Согласен с вами. Ни на одном из моих мест работы я не увидел ни одного дизайнера, занимающегося разработкой интерфейса на wpf, все делает программист. А программисты очень не любят писать что то однообразное длинное и повторяющееся
В данном случае за вас в общем виде уже написан, протестирован и готов к использованию конвертер, решающий определенный круг задач в общем виде. Выражение в binding выходит не сложнее того, что позволяет ввести обычный инженерный калькулятор. Если же вы в нем делаете ошибку, то у вас в output появится соответствующее сообщение в стиле binding errors. Если у вас все заработало, то тест пройден и это просто работает. Ошибки, которые вы можете поймать в дальнейшем, могут быть связаны с невалидными или отсутствующими данными, тогда вы увидите теже самые ошибки в output, что и при использовании стандартного binding.
Сложность в сопровождении составляет большой по объему код со сложной запутанной логикой, в данном же случае мы видим обратную ситуацию, кода мало он в одном месте, он выглядит очень просто, значит менять его не ожидая что где то, что то сломается можно без опасений
Не соглашусь с Вами, что «более читаемо и проще имплементировать туже самую логику на уровне view-model» или конвертера. Конвертер выглядит сложнее и пишется дольше, а использование свойств для этих целей во вьюмодели загромождают её.
А что вы имеете в виду под сопровождением конвертера? Часто ли вы сопровождаете InverseBooleanConverter? Какие сложности сопровождения этого решения Вы видите кроме опасения того, что это сторонняя библиотека?
Или у меня второй вариант — давайте так. HR не знает про работу, я не знаю про себя. «Почему вы уволились с прошлого места работы?» -«Вы знаете, я сейчас не могу вам сказать, мне надо свериться, пригласите меня на собеседование и там всё обсудим»)))
Первое, quick converter судя по всему не умеет вынимать из выражения path имена source property. Поэтому они используют простые стандартные шаблоны $p которые без труда можно найти. Из за этого вам приходится лепить эти конструкции с шаблонами а потом еще биндинги отдельно указывать, согласитесь выглядит не очень юзабельно. Я бы не хотел этим загромождать xaml, для меня, как автора либы, вопрос удобства использования стоял принципиально. В моем биндинге в path вы можете писать какие угодно свойства и вложенные в несколько других вью моделей и понескольку раз одно и тоже, словом как вам удобно вытащить данные. А вот свойства типа p0 p1 извините, выглядят как костыль или временное решение
Второе. В quick converter необходимо вручную забивать выражение для обратного биндинга из dependency property к source property. У меня, как описание в статье выше, выражение представляется в виде функции для которой автоматически ищется обратная и новое выражение служит для обратного связывания
Насчет плюсов quick converter: я считаю что уже Linq выражения это уж точно не обязанность представления, это довольно далеко от представления и это должно быть во вьюмодели, кстати это тот случай о котором писал onikiuchika, писать tostring с целью поменять формат выода в path тоже не следует, для этого есть прекрасное свойство string format в стандартном binding.
С учетом этого я не вижу сильных преимуществ quick converter перед моим решением.
Словом, мое решение требует от вас меньше кода, а возможностей, которыми вы реально будете пользоваться, дает больше
Сложность в сопровождении составляет большой по объему код со сложной запутанной логикой, в данном же случае мы видим обратную ситуацию, кода мало он в одном месте, он выглядит очень просто, значит менять его не ожидая что где то, что то сломается можно без опасений
А что вы имеете в виду под сопровождением конвертера? Часто ли вы сопровождаете InverseBooleanConverter? Какие сложности сопровождения этого решения Вы видите кроме опасения того, что это сторонняя библиотека?