图形组件技术杂谈

3,434 views

Published on

讨论了近年来GUI设计模式从MVC,MVP到MVVM的演变,对比了Flex和.NET在设计上的相似性已经存在的缺陷,以TWaver的改进型MVP设计模式提出了统一数据模型的解决方案,提出了Object-View Mapping(OVM)的概念

Published in: Technology, Art & Photos
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,434
On SlideShare
0
From Embeds
0
Number of Embeds
1,284
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

图形组件技术杂谈

  1. 1. 图形组件技术杂谈 •平台技术特性 •设计模式演变 •产品开发经验 林意炜 sailing8036@gmail.com
  2. 2. 绘制方式 -Swing,WinForms,Canvas... drawLine(x1,y1,x2,y2) add(lineComp) drawRect(x,y,w,h) add(rectComp) drawPolygon (x[],y[]) addPolygon(polygonComp) draw... (x,y,z) add...(xcomp,ycomp,zcomp) repaint() remove(component) 组件方式 -Flex,SL/WPF,SVG,HTML... draw effects .. set effects ..
  3. 3. 绘制方式 优势: 学习曲线低,掌握好基本画笔,画刷和刷新机制即可轻松掌 控任何一个像素点,对于需要承载大数据量的应用是优先的 选择 弱势: Graphic低级的API,导致当应用需要动画,滤镜,扭曲等特 效时开发者要面对大量基础性工作 综述: 当应用复杂需要高级图形处理和动画 等问题时,如果没有底层平台或第三 方框架支持,其学习曲线低和性能高 的优势将会因这些基础工作的消耗而 不复存在
  4. 4. 组件方式 优势: 基础平台已提供动画,滤镜甚至3D等组件级封装,交互点的处理无 需开发者过多考虑特效的影响;各平台几乎都提供了Declarative式 语言,以及可视化工具的支持 弱势: 无法介入底层Graphic的API会导致部分特殊应用无法实现;目前的 SVG,Flex和SL/WPF等主流平台对于超过五千数量级的元素操作都 已相当吃力,过万级别的应用一般无法一次性加载,必须依靠后台 的缓存和延迟加载等处理才能得到较好的用户体验 综述: Declarative language和可视化工具容易麻痹开发者和决 策者,轻视组件式平台的内部复杂性:Flex开发者如果不 了解invalidateProperties,invalidateSize和 invalidateDisplayList的区别,SL/WPF开发者如果不了 解定义DependencyProperty时AffectsRenderer和 AffectsMeasure的意义,那对于产品或项目的开发将像赌 博一样风险巨大
  5. 5. 求异存同 Canvas + SVG + HTML SWT + Swing WinForms + Flex Delphi + Swing Native App + Web
  6. 6. 融合的烦恼
  7. 7. 设计模式进化论 - MVC,MVP,MVVM Mid TierClient DB 现代GUI设计模式具备的基本特性: •从单个元素属性(property change),到数据容器(add,remove)都具备事件派发能力 •Model承载数据并事件派发,并不知道View的存在,一个Model数据可同时为多个View提供服务 •View可以通过监听Model事件变化做相应界面更新,并能将界面操作的结果更新回写入Model http://martinfowler.com/eaaDev/uiArchs.html http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
  8. 8. MVP/MVVM架构的优势 开发者可以投入更多精力在业务数据存取及逻辑处理,甚至不用了解最终界面如何呈现 单元测试无需后台连接也可进行,甚至无需View也可对ViewModel层进行单元测试 Designer和Developer可以更好的分工,更容易的融合,更方便的置换界面风格
  9. 9. 如果说好的商业模式应当一句话说得明白,现代GUI设计框架称之为OVM会更容易被人理解和接受 可类比数据持久层的ORM( object-relational mapping ),ORM通过面对对象屏蔽各种关系数据库 的异构性,使得数据库操作代码易于编写,阅读和维护,甚至不需改动实现不同数据库的迁移 同理OVM通过面对对象屏蔽View的异构性,只需基本的OO代码即可操作不同的View组件,同样易于编 码,阅读和维护,甚至可以用同一套Java业务逻辑代码同时驱动Swing,SWT和JavaFX界面,可以用同 一套C#业务逻辑代码同时驱动WinFroms,Silverlight和WPF界面 .. Object-View Mapping
  10. 10. Presentation Model层设计的思考 - Flex和.NET设计的相似性和缺陷
  11. 11. Presentation Model层设计的思考 •统一的数据模型,明确的事件接口 •统一的SelectionModel,可于PM层实现联动,View层也可独占 •统一的Sort,Filter等配置接口,并从PM层分离,转移到View层 •统一的数据持久化方式,实现不同语言平台的互连互通方案 Cost ViewsTable Tree Sheet Chart … … … 统一模型的一次性学习成本 不同View自有特性学习成本 非统一模型带来的学习成本 不同View对PM的解释 不同View对SM的设计 … … - TWaver的设计模式 统一模型的设计必然会引入一定的入侵性,但换来的是组件内部 设计代码更精简更高效,组件外部使用只有一次性的学习成本, 产品和项目的测试维护都将更加容易
  12. 12. 产品开发个人经验 •发现做梦都在思考如何将她做得更好的产品方向最为关键,如果你觉得有点勉强,一 定不要凑合,继续寻找属于你的方向 •如果深信自己的路线是正确可行的,即使大部分人都反对时,也有必要继续“固执” 下去,因为有了上一条的基础,你有可能是这个领域的专家,至少是长期思考者,而 真理往往掌握在少数人手中,继续“固执”走下去的你很可能就是那少数者 •这是个充满机遇的时代,一旦掌握了某个技术你可以考虑做很多产品,一旦做成了一 个产品你可以考虑做很多衍生产品,但世上没有哪个领域是完美的,即使在你已成专 家的领域依然有发展完善的空间,受诱惑分心尝试不是自己最喜欢最擅长的方向,很 可能会踏空
  13. 13. Nothing Happens Unless First A Dream Q & A

×