ListBox.DisplayMember = [String] Могу ли я как-то обойти это, чтобы оно отличалось от строки в .NET?

Вопрос задается в отношении Object DataSource. Итак, учтите, что у меня есть класс

public class Customer{

    public String name;
    public int age;

    public Customer(String name, int age) {
         this.name = name;
         this.age = age;
    }
}

И у меня есть привязка списка к списку этих объектов. Так что я говорю

listBox.DisplayMember = "name";

Но мой вопрос в том, что когда я реорганизую имя моего класса Customer, чтобы

public String fullName;

DisplayMember по-прежнему остается на «имя». Это не удастся. Таким образом, это снижает мою способность рефакторинга объектов предметной области. Есть ли способ обойти это?


.net data-binding refactoring strong-typing
person Jey Geethan    schedule 15.06.2009    source источник
comment
Проверьте ответ здесь: stackoverflow .com/questions/1984165/   -  person Jey Geethan    schedule 01.03.2010

Ответы (7)


arrow_upward
1
arrow_downward

Единственный способ, который я нашел для этого, - использовать дополнительные свойства для объектов, поэтому имейте

string DisplayMember
{
    get { return 'name'; }
}

и когда вы реорганизуете свой объект, вам нужно только изменить возвращаемую строку на ваше новое имя свойства, сделав его изменением в одном месте, а не в нескольких.

Это не здорово, но работает лучше, чем жесткое кодирование в приложении!

ХТН

Один выстрел

person OneSHOT    schedule 15.06.2009
comment
Хорошая идея и простая в реализации, +1. Очевидно, не идеально, но, как вы сказали, лучше, чем жестко кодировать везде в приложении. - person Meta-Knight; 15.06.2009

arrow_upward
5
arrow_downward

Это более привлекательное и гибкое решение.

Фрагмент...

Короче говоря, вместо того, чтобы писать:

textBoxCustomerName.DataBindings.Add("Text", bindingSource, "CustomerName");

мое предложение состоит в том, чтобы написать что-то вроде:

dataSource.CreateBinding(textBoxCustomerName, ctl => ctl.Text, data => data.Name);

Таким образом, ваш код по-прежнему будет работать без проблем при рефакторинге ваших сущностей (скажем, если вы переименуете свойство Name клиента в CompanyName).

Довольно мило, а?

Также здесь приведены некоторые решения Как сделать тип привязки данных безопасным и поддержка рефакторинга

person Allen Rice    schedule 17.02.2010

arrow_upward
1
arrow_downward

Если вы оставите DisplyMember пустым, тогда ListBox будет использовать ToString() по умолчанию. Когда вы переопределяете эту функцию в своем классе, в списке будет отображаться соответствующее значение. Затем, если вы измените имя поля, ваша сборка сломается в функции ToString().

person Jorg Visch    schedule 15.06.2009

arrow_upward
1
arrow_downward

Начиная с C# 6.0, вы можете использовать оператор nameof, который возвращает имя переменной/элемента/типа в виде строки.

listBox.DisplayMember = nameof(Customer.Name);

(при условии, что есть класс с именем Customer со свойством Name в нем)

Из официального справочника по языку:

Использование nameof помогает сохранять ваш код действительным при переименовании определений.
Раньше вам приходилось использовать строковые литералы для ссылки на определения, что было ненадежным при переименовании элементов кода, поскольку инструменты не знают, как проверять эти строки. литералы.

(выделено мной)

person Ghost4Man    schedule 20.11.2018

arrow_upward
0
arrow_downward

Вот почему вы должны использовать свойства, а не общедоступные поля для предоставления данных из ваших классов. Вы можете более легко реорганизовать внутреннюю работу, не ломая слишком много. Хотя, конечно, будут случаи, когда вам, возможно, придется что-то сломать.

person Rad    schedule 15.06.2009

arrow_upward
0
arrow_downward

ReSharper может сделать это за вас... попробуй - действительно отличная программа. Вероятно, CodeRush тоже может это сделать. Но я не уверен.

person tanascius    schedule 15.06.2009

arrow_upward
0
arrow_downward

Единственный реальный способ, который я нашел, чтобы «обойти» эту «проблему», - это добавить новое общедоступное свойство ReadOnly. Назовите это свойство «ListDisplay» или что-то подобное. Затем вы можете изменить реализацию без какого-либо влияния на пользовательский интерфейс.

Это не идеальная ситуация, но она работает.

person Mitchel Sellers    schedule 15.06.2009