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

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

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

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

string value = (string)combobox1.SelectedItem;

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

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

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

Я что-то упускаю или это просто еще один пример не вполне продуман управления?

8
.net c# generics winforms

6 ответов

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

Я проверил метод addChild метод ComboBox. Он принимает параметр объекта (ugh).

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

Извините, что нет окончательного ответа "почему", просто разделяя общее страдание от необходимости бросать при работе с пользовательским интерфейсом.

3

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

1

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

1

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

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

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

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

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

1

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

1

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

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

1