|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
Алексей КSeVaСценарий не угадан. INotifyPropertyChanged нужен еще для свойств самой коллекции.Какой-то редкий случай. Надо просто помнить об этом и этого достаточно. Из-за этого не применять DataTable когда он удобен глупо. SeVaТы только дал подтверждение тому, что возникают лишние накладные расходы на ровном месте, тк для каждой строки создается отдельный view.Который не хранит никаких данных, является тупо передастом для DataRow. По сравнению со всем остальным это мелочи. 1.Сценарий простой и весьма распространенный - привязка к List.Count. Используется весьма часто: показ общего кол-ва, постраничный вывод, скрытие\показ контролов в зависимости от наличия записей и тд. 2. WPF сам по себе жрет памяти немерянно(простой грид на 10K записей спокойно отъедает 100Mб), а если к этому добавить еще дополнительные "простые" передасты, то будет совсем хорошо. Глупо пользоваться ущербными приблудами, которые разрабатывались до wpf, и на которые он совершенно не заточен. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2012, 08:25 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
SeVaпростой грид на 10K записей спокойно отъедает 100Mб припоминается мне, что некий мембер тут горлопанил, что гриды - это прошлый век.... а уж на 10К записей - это вообще маразм ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2012, 11:06 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
SeVa1.Сценарий простой и весьма распространенный - привязка к List.Count. Используется весьма часто: показ общего кол-ва, постраничный вывод, скрытие\показ контролов в зависимости от наличия записей и тд.Mode=OneTime SeVa2. WPF сам по себе жрет памяти немерянно(простой грид на 10K записей спокойно отъедает 100Mб),Там виртуализация. Там зависит не от общего числа записей, а от одновременно отображаемых на экране. SeVaа если к этому добавить еще дополнительные "простые" передасты, то будет совсем хорошо.Хуже не будет, никто и не заметит. SeVaГлупо пользоваться ущербными приблудами, которые разрабатывались до wpf, и на которые он совершенно не заточен.Говорят же, в некоторых случаях они удобны. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2012, 11:45 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
Алексей КSeVa1.Сценарий простой и весьма распространенный - привязка к List.Count. Используется весьма часто: показ общего кол-ва, постраничный вывод, скрытие\показ контролов в зависимости от наличия записей и тд.Mode=OneTime SeVa2. WPF сам по себе жрет памяти немерянно(простой грид на 10K записей спокойно отъедает 100Mб),Там виртуализация. Там зависит не от общего числа записей, а от одновременно отображаемых на экране. SeVaа если к этому добавить еще дополнительные "простые" передасты, то будет совсем хорошо.Хуже не будет, никто и не заметит. SeVaГлупо пользоваться ущербными приблудами, которые разрабатывались до wpf, и на которые он совершенно не заточен.Говорят же, в некоторых случаях они удобны. OneTime - кургузый огрызок. В итоге пришли к тому, что я утверждал с самого начала. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2012, 19:18 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
ШайтанSeVaпростой грид на 10K записей спокойно отъедает 100Mб припоминается мне, что некий мембер тут горлопанил, что гриды - это прошлый век.... а уж на 10К записей - это вообще маразм Некий мембер работает в разных конторах и на разных этапах. В предпоследней доводилось заставлять шевелиться гриды и убирать memory leak с таким кол-ом записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2012, 19:22 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
SeVa, А как вы предлагаете решить такую задачу: в некоем сравочнике БД появилась потребность добавить поле. В случае с DataTable это вообще не проблема. В случае с ObservableCollection придется изменить модель, а может и не только. Потом я не нашел у ObservableCollection поддержки добаленных/удаленный/измененных записей(OnCollectionChanged - не в счет), у DataTable это есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2012, 21:37 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
SeVaШайтанпропущено... припоминается мне, что некий мембер тут горлопанил, что гриды - это прошлый век.... а уж на 10К записей - это вообще маразм Некий мембер работает в разных конторах и на разных этапах. В предпоследней доводилось заставлять шевелиться гриды и убирать memory leak с таким кол-ом записей. имхо, ты вообще не переставляешь чем ты говоришь. немного нереиргал ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 04:16 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
iscrafmSeVaпропущено... Некий мембер работает в разных конторах и на разных этапах. В предпоследней доводилось заставлять шевелиться гриды и убирать memory leak с таким кол-ом записей. имхо, ты вообще не переставляешь чем ты говоришь. немного нереиргал Это ты сидишь один в коморке и перЕставляешь свое старье с dataset'ами. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 07:03 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
thunder2SeVa, А как вы предлагаете решить такую задачу: в некоем сравочнике БД появилась потребность добавить поле. В случае с DataTable это вообще не проблема. В случае с ObservableCollection придется изменить модель, а может и не только. Потом я не нашел у ObservableCollection поддержки добаленных/удаленный/измененных записей(OnCollectionChanged - не в счет), у DataTable это есть. Меняем модель, а дальше framework должен обеспечивать поддержку всего необходимого. Отслеживание добаленных/удаленный/измененных записей - это только одна из задач. С одними DataTables борьба с ними будет весьма затруднительна ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 07:08 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
[quot SeVa]thunder2SeVa, ... а дальше framework должен обеспечивать поддержку всего необходимого. Вот с этим-то как раз и проблема. Не совсем представляю как в ObservableCollection в run-time вставлять другую модель. С помощью рефлексии создать объект и заполнить его можно, а чтобы вставить в OC её придётся типизировать к некоему общему классу для всех классов Модели . Далее работать с этим придется через рефлексию. Будет ли в этом случае возможна декларативная привязка (из кода понятно, что можно) ? Может есть какой пример того как это делается ? Буду весьма признателен. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 11:22 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
ICustomTypeDescriptor (это старый механизм, используется в частности в DataRowView) или DependencyObject с набором DependencyProperty в качестве элемента коллекции и никакой рефлексии ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 12:09 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
[quot thunder2]SeVaпропущено... Вот с этим-то как раз и проблема. Не совсем представляю как в ObservableCollection в run-time вставлять другую модель. С помощью рефлексии создать объект и заполнить его можно, а чтобы вставить в OC её придётся типизировать к некоему общему классу для всех классов Модели . Далее работать с этим придется через рефлексию. Будет ли в этом случае возможна декларативная привязка (из кода понятно, что можно) ? Может есть какой пример того как это делается ? Буду весьма признателен. Я правильно понял, интересует, что будет, если в коллекции солянка из разных типов? Если это так, то в СО задаешь родительский класс, далее для всех типов создаешь DataTemplate, а wpf/sl5 при binding'е сами выберут нужный шаблон для показа текущего объекта. Смотри доки и примеры для implicit template ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 16:56 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
[quot SeVa]thunder2пропущено... Я правильно понял, интересует, что будет, если в коллекции солянка из разных типов? Не совсем. Если мы берем OC для хранения экземпляров моделей, то в случае программирования исходя из неизменчивости структуры БД всё выглядит красиво, но если в процессе эксплуатации БД надо изменить структуру той или иной таблицы (возмем случай расширения столбцов). Надо заменить модель. Допустим. Мы может реализовать автоматическую генерацию исходника моделей для новой структуры БД, скомпилировать в сборку. А что дальше ? Будет ли работать уровень VM ? Видимо нет. Можно конечно запрограммировать так, чтобы в ОС вставлялись, ну скажем, экземпляры типа Object (как ниже) Код: c# 1.
или экземпляры какого другого класса Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72.
(но всё что вставляется в ОС будет одного типа). Разумеется мы будем использовать приведение типов. Тогда можно будет вставлять в такую коллекцию любые Модели унаследованные от Model. Но как в этом случае делать декларативную привязку ? Ведь в слое VM нет никакой информации о "новых" свойствах. Или же WPF настолько умен, что может по указанному имени в разметке XAML связаться с нашим "новом" свойством ? Я просто не делал так никогда потому не уверен, что привязка будет работать. Обычно всё объекты, их типы, свойства известны на момент компиляции и в таком случае вопросов не возникает, а тут у нас известен по-сути лишь один тип Model с двуми свойствами. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2012, 19:15 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
wpf/sl - это совершенно отдельные истроии. Их binding аналогов не имеет. Привязка в xaml осуществляется во время исполнения. Это позволяет полностью отвязаться от view и загружать его при необходимости из внешнего источника. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2012, 10:03 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
SeVawpf/sl - это совершенно отдельные истроии. Их binding аналогов не имеет. Не совсем понял, про sl речи нет вообще. SeVaПривязка в xaml осуществляется во время исполнения. Это позволяет полностью отвязаться от view и загружать его при необходимости из внешнего источника. Собственно это и требуется. Спасибо. P.S. А не из-за того ли так тормозит TreeView что в WPF привязки создаются в run-time ? Сделал класс, который совместно с TreeView строит файловое дерево. Дебагером смотрел, списки создаюбтся мгновенно, а само дерево строиться ппц как долго. Каталог Windows\System32, например, грузиться аж 8 секунд. И ускорить никак не получается. Хоть пишт свой TreeView. Если он будет также тормозить с данные из БД нафиг бы он нужен был такой. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2012, 21:50 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
thunder2P.S. А не из-за того ли так тормозит TreeView что в WPF привязки создаются в run-time ? Сделал класс, который совместно с TreeView строит файловое дерево. Дебагером смотрел, списки создаюбтся мгновенно, а само дерево строиться ппц как долго. Каталог Windows\System32, например, грузиться аж 8 секунд. И ускорить никак не получается. Хоть пишт свой TreeView. Если он будет также тормозить с данные из БД нафиг бы он нужен был такой.Там по дефолту виртуализация отключена. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2012, 06:46 |
|
ObservableCollection vs DataSet ?
|
|||
---|---|---|---|
#18+
Алексей Кthunder2P.S. А не из-за того ли так тормозит TreeView что в WPF привязки создаются в run-time ? Сделал класс, который совместно с TreeView строит файловое дерево. Дебагером смотрел, списки создаюбтся мгновенно, а само дерево строиться ппц как долго. Каталог Windows\System32, например, грузиться аж 8 секунд. И ускорить никак не получается. Хоть пишт свой TreeView. Если он будет также тормозить с данные из БД нафиг бы он нужен был такой.Там по дефолту виртуализация отключена. Спасибо попробую. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2012, 11:51 |
|
|
start [/forum/topic.php?fid=21&msg=37614555&tid=1441986]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 314ms |
total: | 436ms |
0 / 0 |