|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
D129, Prism для WPF действительно сложный. Для WinApp он как-то лучше выглядит. А так MVVM Light рулит ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 15:54 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
netivanАлексей Кпропущено... Вся модель содержимого (content model) строится на композиции. ContentControl, ItemsControl и т. д. http://www.stauffware.com/d_and_d/dotNet/WPF_UIElement_inheritance.png м?Не, там речь о визуальном наследовании с поддержкой дизайнера. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 18:38 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
hVosttАлексей КНу почему же... В принципе заманчиво поместить в базовую форму ToolStrip с основными кнопками (добавить, изменить, удалить и т. п.) и DataGridView. В в унаследованной форме добавить кнопок в ToolStrip и задать колонки в DataGridView под конкретный источник данных. Но не судьба... такие вещи лучше делаются не через дизайнера. тулстрипы могут быть отцепляемыми и переносимыми, скрываемыми пользователем, скрываемыми по условиям, вся эта пользовательская настройка должна сохраняться. все действия на кнопках адресуются менеджеру команд, т.е. вообще нет смысла задавать евенты на кнопки через дизайнера. иконки и текст на кнопках тоже через дизайнера нет смысла задавать, это лучше через слой интернационализации.. вообще нахрен этот дизайнер впился, так до сих пор и не пойму. чтобы какая-нибуд Люся, не окончившая ПТУ могла мышкой кнопку с панели инструментов притащить? бред в общем.В целом я согласен. Но тут беда в том, что в WinForms нет языка разметки для декларативного описания формы, а на C# это описывать несколько неудобно. В WPF с этим гораздо лучше, в нём работать без дизайнера достаточно удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 18:44 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
Алексей КВ целом я согласен. Но тут беда в том, что в WinForms нет языка разметки для декларативного описания формы, а на C# это описывать несколько неудобно. В WPF с этим гораздо лучше, в нём работать без дизайнера достаточно удобно. наверное, от части, поэтому WPF и был изобретён :) согласен. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 19:01 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
D129Призм же сразу выходит с оговорками - он для "мегаапликаций".Эти оговорки меня просто убили. Я как-то уже их цитировал, повторюсь: Проблема: монолитные приложенияЗатем, для соединения всего вместе, надо будет использовать маршрутизированные события (RoutedEvent), маршрутизированные команды (RoutedCommands) и привязку данных. Эта тема подробнее освещается в статье Брайана Нойеса (Brian Noyes) «Understanding Routed Events and Commands in WPF» («Понимание маршрутизированных событий и команд в WPF»), которая вошла в этот выпуск журнала (msdn.microsoft.com/magazine/cc785480). PositionGrid имеет связанную RoutedCommand для выполнения выбора. В обработчике этой команды Execute при каждом выборе позиции происходит событие TickerSymbolSelected. TrendLine и NewsReader привязаны к нему, они ждут события TickerSymbolSelected и визуализируют свое содержимое, основываясь на выбранном биржевом коде. В данном случае приложение тесно привязано к каждому элементу управления. Для координации всех различных частей в интерфейсе пользователя имеется значительный объем логики . Также существует взаимозависимость между элементами управления.Для начала надо изучить возможности WPF, а потом делать выводы и, тем более, давать советы окружающим. Тогда не будет "значительного объёма логики" для интеграции различных частей между собой. И всё там будет нормально и с независимостью контролов друг от друга, и с параллельной разработкой и со всем остальным. Всё это решается описанием свойств зависимостей прикладного назначения и банальным биндингом различных частей UI между собой, описанных в виде CustomControl или UserControl, в зависимости от потребностей.. И как после этого можно верить авторам сего поделия, если "оговорки" тянут на премию "Шариков - сентябрь, 2008"? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 19:04 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
hVosttICollection и ICollection<T> -- разные по смыслу и замыслу интерфейсы, это совсем не тоже самое «только с типом». это и касается IDictionary/IDictionary<T>.Неправда. Коллекция по своей сути - это "Add", "Count" и итератор. Не больше и не меньше. Все недженерик коллекции имеют в том или ином виде операции добавления. Так почему не вынести Add на интерфейс? И да, ICollection и ICollection<T> - это абсолютно одинаковые по замыслу интерфейсы. Но только первый реализован криво - какой сомнительной компетентности проектировщик не добавил туда Add. Идиотизм. hVosttвсё логично, если подумать тем местом, что называется голова. я же сказал ICollection и ICollection<T> никак не коррелируют друг с другом, да и были спроектированы с довольно большим интервалом времени. кое что доосмыслилось при проектировании типизированных коллекций, а старое менять нельзя, надеюсь сам понимаешь почему. очень надеюсь.Неправда. Вы уже дважды сказали глупость, что они, дескать, не коррелируют. Ну тогда откройте эти парные интерфейсы в соседних вкладках, и переключаясь между ними, убедитесь, что IDictionary<> и IDictionary реализуют абсолютно одни и те же базовые методы (игнорируем ненужную шелуху вроде "IsSyncrionzied"). Аналогично и с ICollection<> и ICollection за тем исключением, что разработчики языка забыли добавить в ICollecton методы Add, Remove и Contains, создав тем самым бесполезного и уродливого монстра. По поводу ConcurrentBag ваш аргумент так же не катит по аналогичной причине. Добавлять в него можно? Да. Удалять можно? Да. Count брать можно? Да. Так почему он не имплементирует ICollection<>? Потому что коллекции в .Net плохо спроектированы, другого объяснения нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 23:45 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjvПотому что коллекции в .Net плохо спроектированы, другого объяснения нет. Вы верно отметили, что нетипизированные варианты - древние жить не мешает, на недостатки - глубоко насрать ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2014, 23:55 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjvКоллекция по своей сути - это "Add", "Count" и итератор. Не больше и не меньше. Все недженерик коллекции имеют в том или ином виде операции добавления. Так почему не вынести Add на интерфейс? И да, ICollection и ICollection<T> - это абсолютно одинаковые по замыслу интерфейсы. Но только первый реализован криво - какой сомнительной компетентности проектировщик не добавил туда Add. Идиотизм.IList и List<T> нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 09:45 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
Алексей КIList и List<T> нет?Каждый лист это коллекция. Не каждая коллекция это лист, ибо операция получения элемента по индексу зачастую не имеет смысла (напр., HashSet). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 09:53 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjv, Зачем спорить? Сказали же, что нетипизированные коллекции чего-либо - это анахронизм... Может в Java и привычно писать ArrayList, в .Net предпочитают типизированные варианты. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 10:15 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjvАлексей КIList и List<T> нет?Каждый лист это коллекция. Не каждая коллекция это лист, ибо операция получения элемента по индексу зачастую не имеет смысла (напр., HashSet).Ну и что? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 10:23 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjvНеправда. Вы уже дважды сказали глупость, что они, дескать, не коррелируют. Не коррелируют, ещё раз говорю. Похожие интерфейсы даже буква в букву ничего не означает. Типизированные и нетипизированные коллекции по определению -- разные. С нетипизированными сегодня практически уже нет смысла работать. Вообще. Нужно хранить объекты неизвестного типа? ICollection<Object>, про старые интерфейсы можно забыть и выкинуть на помойку. Они оставлены для совместимости. Поэтому прекращайте сношать мозг в жёсткой форме. cdtyjvПо поводу ConcurrentBag ваш аргумент так же не катит по аналогичной причине. Добавлять в него можно? Да. Удалять можно? Да. Count брать можно? Да. Так почему он не имплементирует ICollection<>? Потому что коллекции в .Net плохо спроектированы, другого объяснения нет. Не должен ни в коем случае. Даже если методы вроде бы похожи. Здесь я полностью согласен с разработчиками. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 10:29 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjv, отчасти согласен с вашим недоумением.. по поводу ICollection и ICollection<T> Где то на форуме один дядька (от туда) сказал. Типа такого: ICollection ну не оправдал наших надежд, получился уродцем в имплементации дженериков, вместо него создали ICollection<T>, а это недоразумение приходится таскать за собой.. По поводу ConcurrentBag vs ICollection, тут все наверное сложнее, как бы выскажу личное мнение. Все скорее завязано с могопоточностью, мы привыкли работая с ICollection садить блокировку снаружи, там есть такой метод Contains, который вообще бесполезен в конкурентной коллекции. Если учесть что совпадение не желательны ( мешок превращается в лист) мы производим не аттомарное добавление, проверяем есть ли? - если нет адд, так вот между проверкой и Add какой нибудь негодяй может вставить уже такое значение из другого потока, исключение конечно не получим но мешок останется, или садим блокировку с наружи, что уже будет курьёзом. Поэтому и не отнаследовали его от ICollection, что бы не будить лихо. Было бы конечно это хорошо, если бы,ConcurrentDictionary наследует ICollection, хотя и в явном виде (( Тут уже можно получить фокусы с с сообщениями об ошибках. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
зы в System.Collections.Concurrent ничего сокрального нет, все они реализованы на связных списках, вся скрытая блокировка через ядерные мониторы.. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:13 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
Где-то в степи, если уж разбираться, что в .NET действительно вызывает полнейшее недоумение, это архитектура исключений. а с коллекциями как раз проблем никаких нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:29 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
hVosttГде-то в степи, если уж разбираться, что в .NET действительно вызывает полнейшее недоумение, это архитектура исключений. а с коллекциями как раз проблем никаких нет. а что с ней не так? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:30 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
hVosttНе коррелируют, ещё раз говорю. Похожие интерфейсы даже буква в букву ничего не означает. Типизированные и нетипизированные коллекции по определению -- разные. С нетипизированными сегодня практически уже нет смысла работать. Вообще. Нужно хранить объекты неизвестного типа? ICollection<Object>, про старые интерфейсы можно забыть и выкинуть на помойку. Они оставлены для совместимости. Поэтому прекращайте сношать мозг в жёсткой форме.Вы не отличаете интерфейсы от имплементаций. За сим предлагаю закончить. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:36 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
kmawhVosttГде-то в степи, если уж разбираться, что в .NET действительно вызывает полнейшее недоумение, это архитектура исключений. а с коллекциями как раз проблем никаких нет. а что с ней не так? человечьей логике сия архитектура плохо соответствует, в общем Рихтер уже об этом всё высказал ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:37 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
hVosttkmawпропущено... а что с ней не так? человечьей логике сия архитектура плохо соответствует, в общем Рихтер уже об этом всё высказал а где почитать? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:38 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjvВы не отличаете интерфейсы от имплементаций. За сим предлагаю закончить. если сказать вам по существу нечего, то конечно надо закончить. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:39 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
kmawа где почитать? РихтерСпециалисты Microsoft хотели сделать тип System.Exception базовым для всех исключений, а два других типа, System.SystemException и System.ApplicationException , стали бы его непосредственными потомками. Кроме того, исключения вброшенные CLR, стали бы производными от типа SystemException , в то время как исключения, появившиеся в приложениях, должны были наследовать от ApplicationException . Это дало бы возможность написать блок catch , перехватывающий как все CLR-исключения, так и все исключения приложений. Однако на практике это правило соблюдается не полностью; некоторые исключения являются прямыми потомками типа Exception , некоторые CLR-исключения наследуют от типа ApplicationException , а некоторые исключения приложений -- от типа SystemException . Из-за этой путаницы типы SystemException и ApplicationException не несут никакой особой смысловой нагрузки. В настоящее время Microsoft подумывает вообще убрать их из иерархии классов исключений, но это невозможно, так как приведёт к нарушению работы уже имеющихся приложений, в которых используются эти классы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 11:54 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjvhVosttНе коррелируют, ещё раз говорю. Похожие интерфейсы даже буква в букву ничего не означает. Типизированные и нетипизированные коллекции по определению -- разные. С нетипизированными сегодня практически уже нет смысла работать. Вообще. Нужно хранить объекты неизвестного типа? ICollection<Object>, про старые интерфейсы можно забыть и выкинуть на помойку. Они оставлены для совместимости. Поэтому прекращайте сношать мозг в жёсткой форме.Вы не отличаете интерфейсы от имплементаций. За сим предлагаю закончить. запутался свеном в интерфейсах :) В чем ваша проблема? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 12:01 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
cdtyjv Вы не отличаете интерфейсы от имплементаций. За сим предлагаю закончить. Я хоть учился на токаря, но точно знаю, что в профильных вузах на первом или втором курсе изучают такие структуры данных, как очередь и стек. Какой нафик в них Add? Задача ICollection обеспечить конкурентный доступ, копирование и получение информации о размере. Далее, если бы ICollection имел Add и ICollection<T> наследовался от него, какой вызывать, Add(object) или Add(T)? В момент разработки ICollection знали, что будет ICollection<T>! Далее, при разработке ICollection<T> посчитали, что о потокобезопасности надо заботиться в другом месте(видимо задумывались о ns Concurent), а вот ридонливость пригождается часто. Так то вот! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 12:36 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
а может свином не знает IList<T>? всегда им пользуюсь) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 12:53 |
|
Почему в .Net такие убогие коллекции?
|
|||
---|---|---|---|
#18+
я думаю, что надо прекращать метать бисер. это обыкновенный толстый троллинг, без малейшего желания в чём-то разобраться. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 13:00 |
|
|
start [/forum/topic.php?fid=20&msg=38681673&tid=1402627]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 309ms |
total: | 461ms |
0 / 0 |