加载中…
个人资料
ParkerWu
ParkerWu
  • 博客等级:
  • 博客积分:0
  • 博客访问:28,065
  • 关注人气:44
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

DevExpress和Telerik桌面控件库的比较

(2018-07-19 10:53:11)
标签:

wpf

devexpress

telerik

控件库

    DevExpressTelerik都是目前在做.NET库方面的专家,他们的产品涉及到桌面/WEB以及跨平台,这里仅就桌面UI中的Winform/WPF进行对比,更深入的一些有关数据控件的加载大数据的性能,未作测试,则不作为比较依据,这里主要针对DevExpress17.2.4和Telerik 2018 R2 SP1进行比较,以WPF控件为主。

     在文章的最后会不定期的更新这两类控件的Bug,或者是一些遗憾的细节(持续更新中。。。)


1>    库的扩展方式

DevExpress控件应该最早是基于Winform库构建的,然后从中扩展出带.core命名的共享库,用于WPFWeb,从代码与维护来讲,这无疑是比较好的方式,但如果规划不善,就会导致代码冗余,另外就会导致Dll库数量的剧增,而DevExpress肯定是受到了后者的影响,Dll库的数量非常庞大,在使用WPF控件的某些大型控件时,如果是手动添加而不是从工具箱拖放的话,肯定会漏掉不少Dll库的引用。

另外DevExpress有少量的WPF库是直接引用Winform库的,而不是使用带.core的库,从规则上讲很怪异,从另一个方面讲这显然增加了WPF库的尺寸规模,或者说没有为WPF打造自己独有的功能,而只是简单的把Winform库引用过来使用。再比如报表设计控件,WPF的报表设计至少使用了一半以上的Winfrom库,给人的感觉就是使用WPF的代价比Winform大。而DevExpress.Dashboard.Core作为DevExpress.Dashboard.Wpf的核心库,在引用中竟然引用了DevExpress.Dashboard.WinWinform库,不合规则。

 

 Telerik控件的Winfrom库和WPF库是完全分开的两种开发,这两个框架之间很少交互,因此Dll库的数量比较合理,尺寸也很小,虽然对他们自己而言,代码的共享和维护有一定的影响,但对用户来说则只有好处。

总结:Telerik库的DLL数量分配更合理,尺寸更小。

2>    库的规划

Telerik应该是借鉴了系统的.NET规划方式,条理比较清晰,譬如”.Controls”为最基本的核心库,提供一些代码的共享及小型控件,有代表性的如变换动画控件和UI虚拟化的WrapPanel面板;”.Data”为数据处理的核心库,譬如提供了最关键的数据虚拟化;“.Input”则提供常规的输入控件,譬如颜色/日期时间/规则输入/自动完成/组合框/数字输入等小型输入控件;”. Navigation”则提供导航控件,譬如TreeView/TabControl/Breadcrumb/Menu/ToolBar/OutlookBar/PamelBar/Carousel/Book/ LayoutControl/TileView等各类控件;这是四类通用Dll,另外一个就是Data控件库,提供了如数据窗口,数据分页、数据过滤、数据导航等较为适用的小型数据处理控件,其他的譬如/Docking/Ribbon/GridView/等一些大型控件等等都划归为独立的Dll库,如果不使用大型控件,基本上上述四类Dll就够用了。

Devexpress应该是基于以往的自己的独立规划方式,“Data”库为所有库的核心;”Image”提供各种图标的DLL库;“Utils”提供一些帮助类功能的库;相较于Telerik控件,他们还提供了MVVM操作相关的库和Print库,他们在WPF库上划分更细,譬如Accordion/Carousel /TreeMap/Gauges/Map/NavBar/

LayoutControl等都属于独立的Dll库,而在Telerik中,这不过属于导航库和数据可视化库。

     总结:从用户使用的便利性而言,Telerik更方便,而DevExpress则更复杂,因为他们有太多的通用Dll,引用时很容易漏掉。。

3>    提供的功能比较(WPF控件)

A、 小型通用控件

未作详细了解,但感觉Telerik提供的控件种类更丰富,使用更灵活,而DevExpress保持的一贯的注重细节。

B、 Grid控件

这应该是所有控件中最重要的控件了,从Demo的了解来看,双方实现的功能都差不多,很强大,不过Telerik的列调整有一个Bug,那就是当”*”列位于固定宽度列的左边时,在调整列时会出现闪烁调整不方便的情况,而DevExpress的列调整则是完美的,另外DevExpress的Grid可以定义子列,类似Pivot的功能,功能上DevExpress的Grid应该更为强大。

C、 PDF控件

Telerik控件无书签功能(好像正在开发)DevExpress的功能相对比较完善,但在缩小尺寸下,显示的字体发虚,感觉它是根据缩放比例动态调整的,而Telerik的则显示非常清晰,另外在显示大尺寸图像PDF时,DevExpress好像有缓存功能,即第一次加载某页比较慢,第二次回滚时则很快,而Telerik的则仅缓存相连的两页,不知是设置问题,还是其他原因。

D、 Word控件

两者差不多,但Telerik的Word有格式刷,制表格可以移动,插入图片可以编辑,感觉功能更强些,不过所有的DevExpress大型控件都集成了打印预览功能,包括这个Word控件。

E、  Sheet控件

DevExpressSheet控件提供了Chart图标功能,而Telerik没有,DevExpress功能更强大和完善,但DevExpress在高DPI的适应上还有瑕疵,譬如Sheet的行头和列头文字(最新的19.1好像已经改正行头和列头),但Sheet表中的Chart坐标文字及Legend仍旧不适应高DPI,字非常小。

F、  Diagram控件

功能上两者差不多,DevExpress额外提供了Diagram设计控件,而Telerik则不提供,但这不代表DevExpress的功能强,Diagram设计控件可由用户在外部自定义,可由用户去更灵活的实现。另外DevExpress控件好像提供了设计区域,譬如在一张A4的纸张上设计,类似Visio的文档模式,因此可以滚动可见图形区域,而Telerik为整体的放大或者缩小,类似AutoCAD的无限区域绘图模式,个人比较喜欢前者。

G、 计划控件

Demo的使用来看,Telerik有各种时间棒/甘特图与计划控件的搭配应用例子,感觉功能上略强一点,DevExpresa好像还没有提供WPF的甘特图控件。

H、报表控件

Telerik的报表是完全独立的一套控件库,除了在WPFUI上引用了几个标准Dll,其他所有的库都是完全独立的,尺寸相对轻型,主要的就几个Dll,而DevExpress则属于重型报表,将各种Winform的控件库都引用进来了,如果在WPF中使用报表控件的话,含设计时,估计DevExpress2/3Winform控件也必须被引用进来,运行时引用Winform控件比较少;这不知是微软没有公开XAML的设计时,还是其他原因,DevExpressTelerik的报表的VS设计时都是大量使用Winform控件。DevExpress还提供了WPF的报表设计控件,可在运行时设计报表,很强大,而Telerik只有报表运行控件,唯一用于外部报表设计的是用Winform开发的仅作为工具提供。

因此从功能上说DevExpress的报表控件更为强大,但由于大量使用了Winform控件,在WPF中使用报表控件是一场DLL引用的噩梦。

I、   辅助组件

DevExpress提供了Image/MVVM库和打印库,而Telerik则提供了SpreadProcessing/WordsProcessing/PdfProcessing等文档处理库,以及其他一些框架

DevExpress提供的MVVM库很强大,他们还在开源社区发布了带.Free版本的MVVM框架,可用于外部控件库,但那个Image库虽然为用户提供了很大的便利性,但庞大的尺寸也无形的扩大了用户程序的尺寸;DevExpress的打印库应该来说不错,但WPF报表的打印估计是来自Winform的使用,感觉打印预览在高DPI下像Winform窗体中的文字一样模糊发虚(目前发现在报表打印预览上如此)。由于有预览功能,肯定得包含XtraEdit核心库。

  

J、   Charts控件库

从性能上讲,我用过Telerik,性能非常强悍,DevExpress的没用过,不好比较,但我怀疑会低些,因为DevExpress内部更多的集成了各种样式功能,而TelerikChart动画都需要外部定义,个人觉得TelerikChartView性能应该更强大,但没有DevExpress的使用简单。另外吐槽的就是DevExpress3D Chart的鼠标调整功能,反正鼠标动一下后,再想把视图恢复原貌,要调整半天(难道是高DPI下的鼠标偏移?),相反Telerik3D Chart的鼠标调整则肯定是百分百基于鼠标中心调整的,可以方便的恢复原位置,同动画一样,Telerik的智能标签也要在外面独立扩展,而DevExpress提供了完整的标签展现功能。

 

总结:从某些大型控件来说,DevExpress的功能更为强大,细节更加完整,但Dll的数量和尺寸也爆炸式的膨胀,性能上也可能会受到拖累。

 

4>    主题比较

DevExpress的主题数量比Telerik多些,但Telerik至少5个以上的主题提供了颜色盘功能,也就是在某种主题下,如果不修改控件的位置和尺寸,只是改变颜色的话,颜色盘功能就足够了,打比方DevExpressOffice2016主题有6种,但所有控件只是在配色上有变换,在Telerik中只能算是一种主题,配合不同的颜色盘实现即可。因此通过Telerik的颜色盘功能其实可以实现无限的界面配色功能,而这不需要任何额外的DLL主题。

想仔细研究一下Telerik的颜色盘,看它继承的是动态资源,然后又使用了各种解锁和锁定功能,其性能应该比WPF的动态资源强些,此点只是感觉,不明白其原理,不好深入。

 另外DevExpress的大部分控件取消了光标跟踪功能,可能是出于性能的考量,但个人还是喜欢自WinXP来就有的光标感知功能,Telerik控件则保留了所有的光标感知功能,在Fluent主题中,更是借鉴了微软的Fluent设计思想,添加了光标的点光源追踪和离子扩散动画,同时引入了毛玻璃特效,相当酷。

 

5>    启动性能

运行性能没做测试,仅从启动性能上来说,Telerik控件更块,而DevExpress由于其庞大的组件加载,启动比较慢。


补充:最近关注了一下DevexPress的18.23版本的桌面控件,DevExpress确实特别关注Winform控件,估计其针对Winform重新打造了底层的渲染引擎,好像都使用上了Direct2D,之前Winform出现的字体模糊等通病在DevExpress中都不存在,相反其WPF控件库仍旧感觉启动速度比较满,甚至于同一个Chart图表例子,在Winform中拖放很顺滑,而在WPF中却卡顿的不行,唯一针对WPF控件的改进应该是其报表控件的字体显示效果得到很大的提高,已上升至系统级别。

       如果是Winform库,那一定最强的是DevExpress,没有之一,但WPF库就不好说了


2019/6/13日更新:

对于Devexpress 19.1.3 WPF版本有如下明显的问题:

1>Grid控件的列调整组件GridThumb,在每一个列头上只有右列调整,没有左列调整,其结果就是鼠标在靠近列调整线时只能从列的右侧感应到调整(即调整线的左侧感应),而不能从调整线的右侧通过鼠标感应到调整光标,这点连WPF自带的DataGrid都可以从列调整线的左右两侧感应(相反的它的Winform控件就没有此问题)。

2>Spreadsheet控件的Chart内的轴文本和Legend文本都不能自动感应DPI(同样它的Winform控件OK),加载大数据时比较慢,譬如10K数据时,未使用延迟加载,相反Office有明显的延迟加载特性。

3>RichEdit控件不能对内嵌表格进行拖放

4>Carousel控件不支持鼠标滚动项

5>Ribbon控件不支持鼠标滚动切换标签,可参考Office的即可以鼠标滚动标签,也支持拖放

6>Diagram控件的标尺在高DPI下少许文字被遮挡

7>chart控件的性能有提升,但仍旧无法和它的Winform的相比,是否它的WPF chart没有使用直接Direct,还是其他的原因

8>WPF的所有主题几乎都只是更换颜色,尺寸和样式没任何变化,主题控件的尺寸整体偏小,没有像UWP控件的Fluent主题:控件的整体尺寸应该加大,也没有像他的Winform控件的某套主题一样:一套主题从黑色到白色包含各种色系配置。


Telerik 2019 R2 WPF控件:

1>Spreadsheet中的Chart不支持标签,不支持图形更改,不支持数据规则,与DevExpress的比还有差距,在加载大数据,譬如10K数据时,未启用延迟加载

2>GridView控件在有自动列宽时,列调整有Bug,调整很不方便,当对列编组显示后,组头高度和行高度若不一致,在滚动时,不能做到每次滚动行的整数倍

3>RadWindow在高DPI下移动时,鼠标产生漂移的问题一直没解决

4>自定义鼠标光标在高DPI下很小


0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有