Комментарии 33
Подскажите, по каким причинам Syncfusion не рассматривался?
Меня этот вопрос интересует, потому что наш выбор остановился на нем.
Меня этот вопрос интересует, потому что наш выбор остановился на нем.
Пользуюсь программой Технокад-Экспресс, написана с на DevExpress
Самая медленная программа из мне известных. Редактирование проектов, которые в готовом виде занимают 100-300 Кб в XML-ке занимает 10-20 секунд на операцию.
Вы не в курсе, это особенность DevExpress или в большей степени, вероятно, разработчиков?
Самая медленная программа из мне известных. Редактирование проектов, которые в готовом виде занимают 100-300 Кб в XML-ке занимает 10-20 секунд на операцию.
Вы не в курсе, это особенность DevExpress или в большей степени, вероятно, разработчиков?
Сложно сказать. По быстродействию к компонентам DevExpress у нас не было претензий, но на серьезных нагрузках мы их не тестировали.
Скорее все вместе.
В DevExpress часто встречаются тормоза и баги, но если иметь прямые руки, то в итоге все работает стабильно и довольно шустро. Есть поддержка различных механизмов работы с большими объемами данных. Если нет времени писать собственные контролы с богатым функционалом, вполне вариант. Если разработчики не могут победить проблемы со скоростью работы DevExpress, вряд ли они способны эффективно написать собственные контролы.
В DevExpress часто встречаются тормоза и баги, но если иметь прямые руки, то в итоге все работает стабильно и довольно шустро. Есть поддержка различных механизмов работы с большими объемами данных. Если нет времени писать собственные контролы с богатым функционалом, вполне вариант. Если разработчики не могут победить проблемы со скоростью работы DevExpress, вряд ли они способны эффективно написать собственные контролы.
перевести все ресурсы на два языка или же собственная реализация иерархического грида и поддержки WCF DataServices
Мне кажется, в сравнении с допиливанием грида перевод стоит копейки.
Конечно разовый перевод ресурсов будет стоить относительно мало, но и допиливание грида тоже не очень сложная задача с тем условием, что есть кастомные колонки. Но в плане надежности и предсказуемости результата перевод гораздо более предсказуем.
Для наших задач по совокупности факторов все-таки грид от Telerik подходит лучше.
Для наших задач по совокупности факторов все-таки грид от Telerik подходит лучше.
У меня некоторая рассинхронизация произошла, когда начал читать текст. :-)
Думал речь идет об альтернативах Grid-панелей, а тут о DataGrid'ах.
За обзор спасибо. Сами мучились с гридами в одном проекте. Остановились на опенсорсном варианте (уже не вспомню название) и этот кошмар мне до сих пор снится. Неужели нет нормального бесплатного DataGrid с поддержкой TreeView стиля отображения?
Думал речь идет об альтернативах Grid-панелей, а тут о DataGrid'ах.
За обзор спасибо. Сами мучились с гридами в одном проекте. Остановились на опенсорсном варианте (уже не вспомню название) и этот кошмар мне до сих пор снится. Неужели нет нормального бесплатного DataGrid с поддержкой TreeView стиля отображения?
Попробуйте DevComponents DotNetBar for WPF. Не знаю как там грид, а AdvTree (TreeListView) там довольно хороший. Написал разработчикам много багрепортов, теперь пользоваться им приятно. Есть свои неудобства, но виртуализация работает очень хорошо, есть множественное выделение, можно рулить прокруткой и выделением из кода. С гридом я сам почти не работал, но по крайней мере разметка интуитивная.
Здравствуйте, Павел! Большое спасибо за обзор и за конструктивную критику.
Как многие уже возможно слышали, компания DevExpress имеет большой центр разработки в России (http://www.dxrussia.ru), и у нас даже есть небольшой блог на Хабре (http://habrahabr.ru/company/devexpress/). Поэтому, пользуясь случаем, хочу дополнить Ваш пост комментариями нашей команды разработчиков – надеюсь, эти дополнения будут полезными.
1. SelectedItem vs FocusedRow – мы признаём такую проблему и планируем исправить её в ближайшем будущем.
2. Раскраска строк через одну – обязательно сделаем, чтобы тоже работало с помощью выставления одного свойства.
3. По поводу master-detail хотелось бы заметить, что DataControlDetailDescriptor.DataControl – это Content свойство. Таким образом, синтаксис немного сокращается до такого:
Возможно, мы сделаем View или Columns контент-свойством для грида – чтобы еще больше упростить синтаксис. Но, согласитесь, уже получается не сильно длиннее по сравнению с остальными.
По поводу отсутствия отступов между детальным и следующим гридом – обычно горизонтального отступа вполне достаточно для вложенного грида, чтобы визуально отделить детальный грид от мастер грида. Видимо, это дело вкуса.
4. «Так же, при таком подходе байндинг свойства FocusedRow у деталь грида не работает!» Обоснованно. Тут дело в том, что грид, описанный внутри DataControlDetailDescriptor, клонируется для каждого открытого детального грида.
Это сделано для того, чтобы гриды в разных деталях могли полностью синхронизироваться между собой при сортировке, таскании/ресайзинге колонок, фильтрации и т.п. Это одно из основных требований различных пользователей к данной фиче и реализовать его при подходе, основанном на DataTemplate, как у большинства конкурентов, невозможно. Соответственно, и наложить байндинг на FocusedRow этого грида нельзя, нужна возможность задать байндинг для каждого отклонированного грида.
Скорее всего, мы добавим свойство DataControlDetailDescriptor.FocusedRowBinding (SelectedRowBinding), которое позволить прибиндиться к выбранной детальной строке внутри вью модели мастер строки.
5. Байндинг команд контекстного меню. Насколько мы понимаем, это задача сделать контекстное меню для строки или ячейки.
Если контекстное меню задается на уровне всего грида, то в дата контексте этого меню будет то же самое, что у самого грида, то есть будет желаемый результат. Но как при этом добраться до значения этой строки или ячейки, что как раз чаще всего нужно для команд уровня строки/ячейки?
В нашем гриде можно обратиться как к значениям самой строки/ячейки, так и к дата контексту грида. Мы согласны, что это неочевидно, тут нам надо серьезно думать, как упростить этот сценарий.
Как многие уже возможно слышали, компания DevExpress имеет большой центр разработки в России (http://www.dxrussia.ru), и у нас даже есть небольшой блог на Хабре (http://habrahabr.ru/company/devexpress/). Поэтому, пользуясь случаем, хочу дополнить Ваш пост комментариями нашей команды разработчиков – надеюсь, эти дополнения будут полезными.
1. SelectedItem vs FocusedRow – мы признаём такую проблему и планируем исправить её в ближайшем будущем.
2. Раскраска строк через одну – обязательно сделаем, чтобы тоже работало с помощью выставления одного свойства.
3. По поводу master-detail хотелось бы заметить, что DataControlDetailDescriptor.DataControl – это Content свойство. Таким образом, синтаксис немного сокращается до такого:
<dxg:GridControl.DetailDescriptor>
<dxg:DataControlDetailDescriptor ItemsSourcePath="Children">
<dxg:GridControl>
<dxg:GridControl.View >
<dxg:TableView/>
</dxg:GridControl.View>
<dxg:GridControl.Columns>
</dxg:GridControl.Columns>
</dxg:GridControl>
</dxg:DataControlDetailDescriptor>
</dxg:GridControl.DetailDescriptor>
Возможно, мы сделаем View или Columns контент-свойством для грида – чтобы еще больше упростить синтаксис. Но, согласитесь, уже получается не сильно длиннее по сравнению с остальными.
По поводу отсутствия отступов между детальным и следующим гридом – обычно горизонтального отступа вполне достаточно для вложенного грида, чтобы визуально отделить детальный грид от мастер грида. Видимо, это дело вкуса.
4. «Так же, при таком подходе байндинг свойства FocusedRow у деталь грида не работает!» Обоснованно. Тут дело в том, что грид, описанный внутри DataControlDetailDescriptor, клонируется для каждого открытого детального грида.
Это сделано для того, чтобы гриды в разных деталях могли полностью синхронизироваться между собой при сортировке, таскании/ресайзинге колонок, фильтрации и т.п. Это одно из основных требований различных пользователей к данной фиче и реализовать его при подходе, основанном на DataTemplate, как у большинства конкурентов, невозможно. Соответственно, и наложить байндинг на FocusedRow этого грида нельзя, нужна возможность задать байндинг для каждого отклонированного грида.
Скорее всего, мы добавим свойство DataControlDetailDescriptor.FocusedRowBinding (SelectedRowBinding), которое позволить прибиндиться к выбранной детальной строке внутри вью модели мастер строки.
5. Байндинг команд контекстного меню. Насколько мы понимаем, это задача сделать контекстное меню для строки или ячейки.
Если контекстное меню задается на уровне всего грида, то в дата контексте этого меню будет то же самое, что у самого грида, то есть будет желаемый результат. Но как при этом добраться до значения этой строки или ячейки, что как раз чаще всего нужно для команд уровня строки/ячейки?
В нашем гриде можно обратиться как к значениям самой строки/ячейки, так и к дата контексту грида. Мы согласны, что это неочевидно, тут нам надо серьезно думать, как упростить этот сценарий.
Что касается другой функциональности, которую Вы рассматривали в Вашей статье:
1. Ленивая догрузка записей и поддержка WCF DataServices.
Наш грид полностью поддерживает этот режим (у нас он называется Instant Feedback Mode) и полностью поддерживает загрузку записей по требованию, кеширование, оптимизацию объема загружаемых данных в зависимости от пропускной способности канала, сортировку, группировку, фильтрацию, вычисление Summaries полностью на стороне сервера и многое другое.
Пример можно посмотреть в GridDemo/Server-side Data Processing/WCF Data Services (OData), документация по этой ссылке: documentation.devexpress.com/#WPF/CustomDocument9565
2. Древовидный грид.
У нас есть TreeListControl, заточенный под различные режимы отображения древовидных данных. Подробнее можно почитать здесь: documentation.devexpress.com/#WPF/CustomDocument9933
3. Локализация.
Мы предоставляем полную русскую локализацию для всех наших компонентов. Подробнее можно посмотреть в документации: documentation.devexpress.com/#WPF/CustomDocument7544
4. Печать.
Мы полностью поддерживаем печать и экспорт в различные форматы — xls, xlsx, pdf и т.д.
Здесь есть вся информация: documentation.devexpress.com/#WPF/CustomDocument6160
1. Ленивая догрузка записей и поддержка WCF DataServices.
Наш грид полностью поддерживает этот режим (у нас он называется Instant Feedback Mode) и полностью поддерживает загрузку записей по требованию, кеширование, оптимизацию объема загружаемых данных в зависимости от пропускной способности канала, сортировку, группировку, фильтрацию, вычисление Summaries полностью на стороне сервера и многое другое.
Пример можно посмотреть в GridDemo/Server-side Data Processing/WCF Data Services (OData), документация по этой ссылке: documentation.devexpress.com/#WPF/CustomDocument9565
2. Древовидный грид.
У нас есть TreeListControl, заточенный под различные режимы отображения древовидных данных. Подробнее можно почитать здесь: documentation.devexpress.com/#WPF/CustomDocument9933
3. Локализация.
Мы предоставляем полную русскую локализацию для всех наших компонентов. Подробнее можно посмотреть в документации: documentation.devexpress.com/#WPF/CustomDocument7544
4. Печать.
Мы полностью поддерживаем печать и экспорт в различные форматы — xls, xlsx, pdf и т.д.
Здесь есть вся информация: documentation.devexpress.com/#WPF/CustomDocument6160
Словосочетание «Instant Feedback Mode» обозначает ленивую догрузку?? 8-О
Смысл названия Instant Feedback UI в том, что UI никогда не блокируется и пользователь сразу получается отклик на свои действия. А все действия выполняются асинхронно, в другом треде.
А ленивая догрузка — это лишь небольшая часть механизма. Instant Feedback подразумевает гораздо больше всего: и кеширование данных, и группировку на сервере, и вычисление функций и т.д.
А ленивая догрузка — это лишь небольшая часть механизма. Instant Feedback подразумевает гораздо больше всего: и кеширование данных, и группировку на сервере, и вычисление функций и т.д.
Если будут вопросы — задавайте, всегда рады помочь! Писать можно или в нашу официальную службу поддержки www.devexpress.com/sc, или в ветку вопросов на Хабре habrahabr.ru/company/devexpress/questions/, или можете послать сообщение мне лично.
Удачи!
Удачи!
Алексей, большое спасибо за столь развернутый ответ!
Про мастер-деталь грид соглашусь, так стало компактней.
Визуальное оформление деталь грида — это дело вкуса, как вы заметили, и вопрос каждого конкретного прикладного проекта. Поэтому возможность настройки этого отображения является достаточно важным функционалом. В нашем случае, горизонтального отступа не достаточно, потому что зачастую в деталь гриде 3-10 строк, и получается так, что деталь грид отделен от своей мастер-строки, но практически вплотную прилеплен к следующей мастер-строке. Немного режет глаз.
Посмотрел древовидный грид. Выглядит красиво, но в примере разметки видны следы реляционной базы данных:
К сожалению у меня сейчас нет возможность проверить на реальном примере, поэтому спрошу можно ли просто указать поле со связанной коллекцией потомков, например так:
Если можно и это будет работать как и ожидается, то хорошо.
Я повторюсь что высказываю свое субъективное суждение и только относительно WPF грида. Про WinForms компоненты сказать не могу — не пользовался, а вот система построения отчетов полгода назад была одной из лучших и мы выбрали именно ее для одного из наших проектов.
Про мастер-деталь грид соглашусь, так стало компактней.
Визуальное оформление деталь грида — это дело вкуса, как вы заметили, и вопрос каждого конкретного прикладного проекта. Поэтому возможность настройки этого отображения является достаточно важным функционалом. В нашем случае, горизонтального отступа не достаточно, потому что зачастую в деталь гриде 3-10 строк, и получается так, что деталь грид отделен от своей мастер-строки, но практически вплотную прилеплен к следующей мастер-строке. Немного режет глаз.
Посмотрел древовидный грид. Выглядит красиво, но в примере разметки видны следы реляционной базы данных:
<dxg:TreeListControl Name="treeListControl1">
<dxg:TreeListControl.Columns>
<dxg:TreeListColumn FieldName="Column1" />
<dxg:TreeListColumn FieldName="Column2" />
</dxg:TreeListControl.Columns>
<dxg:TreeListControl.View>
<dxg:TreeListView Name="treeListView1"
KeyFieldName="ID"
ParentFieldName="ParentID"/>
</dxg:TreeListControl.View>
</dxg:TreeListControl>
К сожалению у меня сейчас нет возможность проверить на реальном примере, поэтому спрошу можно ли просто указать поле со связанной коллекцией потомков, например так:
<dxg:TreeListControl Name="treeListControl1">
<dxg:TreeListControl.Columns>
<dxg:TreeListColumn FieldName="Column1" />
<dxg:TreeListColumn FieldName="Column2" />
</dxg:TreeListControl.Columns>
<dxg:TreeListControl.View>
<dxg:TreeListView Name="treeListView1" ItemsSource="{Binding Children}" />
</dxg:TreeListControl.View>
</dxg:TreeListControl>
Если можно и это будет работать как и ожидается, то хорошо.
Я повторюсь что высказываю свое субъективное суждение и только относительно WPF грида. Про WinForms компоненты сказать не могу — не пользовался, а вот система построения отчетов полгода назад была одной из лучших и мы выбрали именно ее для одного из наших проектов.
Режим с построением иерархической структуры по плоскому списку (то, что Вы охарактеризовали как «следы реляционной базы данных») – это только один из нескольких доступных в трилисте. Поддерживаются также режимы биндинга через HierarchicalDataTemplate (как в стандартном TreeView) и через указание поля с дочерними записями.
Для указания поля со связанной коллекцией потомков необходимо задать ChildNodesPath и TreeDerivationMode, для Вашего примера это будет:
> Я повторюсь что высказываю свое субъективное суждение и только относительно WPF грида.
По-моему, всё отлично :-) Хабр — место для дискуссий и для обмена мнениями. Нам тоже было очень ценно узнать взгляд на наш продукт со стороны потенциального пользователя, к тому же соотечественника.
Для указания поля со связанной коллекцией потомков необходимо задать ChildNodesPath и TreeDerivationMode, для Вашего примера это будет:
<dxg:TreeListView Name="treeListView1" ItemsSource="{Binding Children}" TreeDerivationMode="ChildNodesSelector" ChildNodesPath="Children"/>
> Я повторюсь что высказываю свое субъективное суждение и только относительно WPF грида.
По-моему, всё отлично :-) Хабр — место для дискуссий и для обмена мнениями. Нам тоже было очень ценно узнать взгляд на наш продукт со стороны потенциального пользователя, к тому же соотечественника.
Спасибо за этот комментарий, иначе бы я из вашей документации никогда бы не понял, что вместе с ChildNodesPath нужно задать ещё и TreeDerivationMode. Кстати, как я понимаю, в вашем примере атрибут ItemsSource будет невалиден.
Полтора года назад сделали выбор в пользу Telerik. Правда, под Silverlight. В принципе, со всеми задачами он справился, окромя полноценного экспорта в Excel, там были какие-то проблемы.
Посылом к рассмотрению стало то, что стандартный грид (а это обычно большая часть функционала пользовательского интерфейса бизнес-приложения)
Интересно, настанут ли когда-нибудь светлые времена, когда «бизнес-приложения» перестанут быть невменяемым нагромождением гридов по 50 столбцов…
Мы в команде на недавней ретроспективе обсуждали вопрос юзабилити интерфейсов. Пришли к выводу, что самым надежным способом разработки великолепных приложений будет «внедрение мыслей в голову заказчика».
Столбцов может быть и меньше.
Пока ничего оптимальней и удобней для восприятия большого количества данных лучше гридов не придумали.
Пока ничего оптимальней и удобней для восприятия большого количества данных лучше гридов не придумали.
А какие альтернативы Вы видите?
Есть один вопрос. А работает ли виртуализация в сложных гридах (в treeGrid или в MasterDetailGrid)?
Добрый день!
Да, работает. То есть для детальных гридов создаются только те строки, которые видны на экране.
Кроме того, при таком подходе как у нас, когда используется один скроллер для мастер и всех детальных гридов, строчки повторно используются даже между различными детальными гридами, что ускоряет раскрытие детальных гридов (если в кеше уже есть строки от предыдущих детальных гридов, которые в данный момент не видны на экране). А также это уменьшает использование памяти при большом количестве открытых детальных гридов благодаря тому, что в каждый момент времени в памяти находится строк не больше, чем помещается на экране.
В трилисте виртуализация, соответственно, тоже полностью поддерживается. То есть строки могут повторно использоваться при скроллинге, expand/collapse, в том числе между нодами, находящимися на разных уровнях.
Да, работает. То есть для детальных гридов создаются только те строки, которые видны на экране.
Кроме того, при таком подходе как у нас, когда используется один скроллер для мастер и всех детальных гридов, строчки повторно используются даже между различными детальными гридами, что ускоряет раскрытие детальных гридов (если в кеше уже есть строки от предыдущих детальных гридов, которые в данный момент не видны на экране). А также это уменьшает использование памяти при большом количестве открытых детальных гридов благодаря тому, что в каждый момент времени в памяти находится строк не больше, чем помещается на экране.
В трилисте виртуализация, соответственно, тоже полностью поддерживается. То есть строки могут повторно использоваться при скроллинге, expand/collapse, в том числе между нодами, находящимися на разных уровнях.
Спасибо за обзор. Можно спросить, на чем в итоге остановились?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Трудный выбор грида для проектов на WPF