Проблема заключается в том, что вы явно установили DataContext
вашего UserControl:
DataContext="{Binding Mode=OneWay, RelativeSource={RelativeSource Self}}
Удалите это назначение и запишите привязку ItemName
следующим образом:
<TextBlock Text="{Binding ItemName,
RelativeSource={RelativeSource AncestorType=UserControl}}"/>
или как это
<TextBlock Text="{Binding ItemName, ElementName=ItemRowControl}"/>
Я лично только использую “var”, когда я могу ясно отличить тип переменной, просто читая объявление, например:
var someVariable = new List<int>();
В примере выше, его очевидное, которое “var” отсылает к “List< int> ”.
я don’t нравится использовать “var”, когда я должен перейти к некоторому определению метода для обнаружения то, что тип переменной “var” представляет или при необходимости полагаться на intelli-всплывающее-окно Visual Studio или независимо от того, что это называют, например, это в не хорошо мне:
var someVaraible = SomeMethod();
я имею в виду, что функция “SomeMethod”, как предполагается, возвращает? Можно ли сказать только путем рассмотрения строки кода? Нет Вы can’t, так, чтобы был то, почему я избегаю использования “var” на тех ситуациях.
Просто легче ввести псевдоключевое слово var время от времени, чем огромное имя типа, особенно если дженерик мог бы быть включен. Однако необходимо знать, что они функционально идентичны. Нет никакого различия в производительности или чего-либо так или иначе. Компилятор получает тип правой стороны присвоения и заменяет var тем типом. Этого не происходит во времени выполнения как вариант VB.
Существует большая дискуссия об этом, но я думаю, что все это сводится к персональному вкусу, точно так же, как использование 'этого' ключевого слова почти везде.
я лично предпочитаю explictly переменные определенного типа, но когда вложенные вещи универсальных наборов использования могут стать большим количеством читаемого использования переменной с неявно определенным типом. Посмотрите на:
Dictionary<string, Dictionary<string, string>> myDictionary = new Dictionary<string, Dictionary<string, string>>();
по сравнению с:
var myDictionary = new Dictionary<string, Dictionary<string, string>>();
РЕДАКТИРОВАНИЕ: это ТАК тема затрагивает ту же тему с некоторыми хорошими ответами: , Что использовать: var или тип имени объекта?
EDIT2: Работая много с асинхронным в наше время, я нахожу, что использование explicity переменные определенного типа может иногда предотвращать противные ошибки. Рассмотрите этот глупый пример, где Вы хотели бы возвратить идентификатор пользователя. Также полагайте что GetUserAsync
возвраты Task<User>
. При использовании переменных с неявно определенным типом Вы закончили бы тем, что использовали что-то вроде этого:
public long GetUserId()
{
var user = GetUserAsync();
return user.Id;
}
Это компилирует, но это неправильно. 'пользователь' на самом деле Task<User>
. И это компилирует, как Task
также имеет Id
свойство. В этом случае можно было бы случайно возвратить идентификатор Задачи вместо Пользователя.
public long GetUserId()
{
User user = GetUserAsync();
return user.Id;
}
Вышеупомянутое не компилирует, поскольку компилятор будет жаловаться, что Вы не можете бросить Задачу Пользователю. При добавлении await
ключевое слово, конечно, решает это.
я на самом деле имел, это происходит со мной однажды:-)
FWIW, ключевое слово var явно читаемо во многих случаях. Особенно, если...
правая сторона присвоения является выражением конструктора.
карта var = новый Словарь> ();
Локальные переменные имеют хорошие имена.
HTH
На всякий случай некоторые еще не заметили, можно легко изменить “предложения” в Формирователе (Формирователь-> Опции-> Языки->, Действия Контекста-> “Заменяют явную спецификацию типа 'var'”).
Я лично предпочитаю иметь явные спецификации типа везде, но я не являюсь слишком суетливым об этом.