WPF соглашения о присвоении имен элемента UI
При необходимости в большей гибкости, чем Формат ссылки Google дает Вам, или требуется встроить карту в приложение вместо того, чтобы запуститься, приложение карты вот пример .
Это даже предоставит Вас исходный код, чтобы сделать все встраивание.
4 ответа
Лично я считаю, что WPF меняет правила, когда дело доходит до этого. Часто можно обойтись без кода или с небольшим количеством кода, поэтому наличие префиксов для различения имен делает вещи более запутанными, а не менее запутанными.
В Windows Forms на каждый элемент управления в коде ссылались по имени. При большом пользовательском интерфейсе полу-венгерская нотация была полезной - было легче различать то, с чем вы работали.
Однако в WPF это редкий элемент управления, которому нужно имя. Когда вам действительно нужно получить доступ к элементу управления через код, часто лучше использовать для этого присоединенные свойства или поведения, и в этом случае вы никогда не имеете дело с более чем одним элементом управления. Если вы работаете в UserControl или Window code-behind, я бы просто использовал «Title» и «Name» вместо «txtTitle», тем более, что теперь вы, вероятно, будете иметь дело только с несколькими ограниченными элементами управления, а не со всеми.
Даже пользовательские элементы управления в большинстве случаев не нуждаются в именах. Вам понадобятся шаблонные имена в соответствии с соглашением (например: PART_Name), но не фактические элементы x: Name для ваших пользовательских интерфейсов ...
По моему опыту - в WPF при изменении типа элемента управления обычно вам не нужно переписывать какой-либо код, если вы не сделали что-то не так. Фактически, в большинстве случаев вы не ссылаетесь на элементы управления в коде. Да, вы в конечном итоге это делаете, но большинство ссылок на элемент пользовательского интерфейса в WPF относятся к другим элементам того же XAML.
Лично мне "lblTitle, lblCompany, txtFirstName" труднее читать, чем "Title". У меня нет .intWidth и .intHeight (прощайте, lpzstrName!). Почему .lblFirstName? Я могу понять TitleField или TitleInput или что-то еще, так как это описывает что, а не как.
Для меня, Желание иметь такой тип разделения обычно означает, что мой код пользовательского интерфейса пытается сделать слишком много - конечно, он имеет дело с элементом пользовательского интерфейса, он находится в коде окна! Если я не имею дело с кодом вокруг элемента пользовательского интерфейса, зачем мне кодировать его здесь?
В WPF вам практически никогда не нужно (и даже не хочется) давать имена элементам управления. Так что, если вы используете лучшие практики WPF, не имеет значения, как вы назвали бы свои элементы управления , если бы у вас была причина называть их.
В тех редких случаях, когда вы на самом деле я хочу дать элементу управления имя (например, для ссылки ElementName = или TargetName =), я предпочитаю выбирать имя, описывающее его назначение, например:
<Border x:Name="hilightArea" ...>
...
<DataTrigger>
...
<Setter TargetName="hilightArea" ...
Мне нравится использовать соглашение (просто хорошая идея в целом), но для пользовательского интерфейса мне нравится, когда тип элемента управления впереди, за которым следует описательное имя - LabelSummary , TextSummary, CheckboxIsValid и т. Д.
Звучит второстепенно, но основная причина для размещения типа первым состоит в том, что они будут отображаться вместе в списке Intellisense - все метки вместе, флажки и т. Д.