Сильно типизированные элементы управления в .NET.

Question

Я работаю над приложением Windows Forms довольно долгое время, и я действительно нахожу, что делаю больше типов в коде графического интерфейса, чем когда-либо в своем базовом бизнес-коде.

То, что я имею в виду, становится очевидным, если вы наблюдаете за элементом управления ComboBox, который принимает какой-то неопределенный «объект» как элемент. Затем вы уйдете и можете отобразить дисплей DisplayMember и ValueMember и т. Д.

Если я хочу получить это значение позже, мне нужно будет возвращать объект обратно к тому, что было. Как со строками получения значения принимает

string value = (string)combobox1.SelectedItem; 

Теперь Поскольку дженерики в рамках в течение достаточно долгого времени, я до сих пор удивляюсь, почему в аду не один контроль из стандартного набора инструментов является универсальным.

Я также обнаружил, что использую свойство .Tag в ListViewItems все время, чтобы сохранить отображаемый объект домена. Но каждый раз, когда мне нужно получить доступ к этому объекту, мне нужен другой тип.

Почему я не могу просто создать ComboBox или ListView с элементами типа ListViewItem

я упускаю что-то здесь, или это просто еще один пример не совсем хорошо продумана управления?

Answer 1

Хотя критика «не использует дженерики» не может быть справедливо применена к средствам управления, разработанным до их существования ... нужно задаться вопросом о элементах управления WPF (новых в .NET 3.0, после дженериков в .NET 2.0) ,

Я проверил способ AddChild в ComboBox. Он принимает параметр объекта (ть).

Этот элемент управления предназначен для использования в основном с помощью XAML. Это было сделано так, потому что нет способа указать параметр типа в XAML? (в стороне, нет способа указать параметр типа в XAML?)

Извините, что не существует окончательного ответа «Почему», просто разделяя общие страдания, связанные с приложением при работе с пользовательским интерфейсом.

Answer 2

Я не думаю, что вам ничего не хватает. Просто эти классы были созданы еще в дни до Generics, а WinForms просто недостаточно режут для MS, чтобы тратить много времени на изменение или расширение API.

Answer 3

Я часто создаю классы-оболочки для элементов управления. Это позволяет использовать дженерики. Это часто связано с Reflection, который не является безопасным во время компиляции, но может быть во время выполнения.

Answer 4

Общий источник этой проблемы, я думаю, не отделяет вашу логику представления/представления от логики модели данных в памяти. К сожалению, это ошибка архитектуры, в которой участвуют WinForms и дизайнер Visual Studio GUI.

WinForms и разработчик VS не поощряют программиста отделять управление своими объектами данных от самих классов форм. Вероятно, было бы лучше, если бы объекты ComboBox ListViewItem не предлагали какую-либо поддержку для произвольных объектов, либо через дженерики, либо коллекции объектов.

Если вы не взломали что-то ограниченное использование и срок службы, вы должны стараться избегать хранения ссылки на отдельные объекты данных прямо в ваших элементах управления или формах.Они должны управляться отдельно, и если им нужно ссылаться, это должно быть сделано с помощью класса управления моделью, предназначенного для определенного типа класса просмотра, с которым вы работаете.

Простая в использовании повязка для проблемы может заключаться в «отображении» текстовых представлений, которые вы помещаете в ComboBox или ListView в исходные объекты, используя член поля «Словарь» в вашем классе Form. Это не идеальное решение, но дает вам хотя бы половину шага косвенности между вашими данными и элементами управления пользовательского интерфейса, которые могут упростить работу с вашим кодом.

Edit: Это правда, отдельно от ListViewItemCollection класса обнажая экземпляров объектов ... Официальная защита, вероятно, что они хотели поддержать стандартные IEnumerable и ICollection интерфейсы. Но нет причин, по которым они не могли бы также предусмотреть переопределения типов этих методов, поскольку они явно предназначены для хранения экземпляров ListViewItem. Поэтому у меня нет ответа на этот вопрос.

Answer 5

Ну, если вы привязываете данные к объекту DataBindingSource, вы можете получить данные в таком виде, но AFAIK, который все еще не сильно типизирован. Если вы показываете несколько параметров/аспектов одного бизнес-объекта, вы можете привязываться к нему, а затем обращаться к ним (строго типизированным) - конечно, это все возвращается к ответу «Турбулентный интеллект», что является лучшим разделением между моделью и Посмотреть. Тем не менее, я согласен с тем, что типичная типизация поможет.

Answer 6

Возможно (вы можете создать свои собственные общие элементы управления, если хотите), но разработчик форм, который поставляется с Visual Studio, будет волноваться, если вы это сделаете. Вам это нужно будет делать без него.

Вы не первый, кто думает об этом, и Microsoft уже получила справедливую долю критики со стороны общественности за это. Будем надеяться, что они добавят поддержку этому в будущем.