解惑

解己之惑,解人之惑

标签:表现层

表现层的一些想法

上次也说过表现层是最难解决的,主要是解决复用和开发速度,目前的一些基本想法:

  • 有一个类似ECS的通用页面基本元素模型
  • 在上面的基本元素的基础上有项目需要的粒度更大一些的组件,例如下拉列表、表格甚至页面模版
  • 页面Builder,根据一定的规则可以自动创建页面的框架,然后开发人员只需要做一些小的调整
  • 和项目的模型层绑定,这样很多地方拿到模型后,使用Builder就可以使用非常少的代码得到外观一致的页面了
  • 引入AJAX,特别是一些过滤条件,根据一定的规则获取并更新到(可能增加一个客户端缓存),特别是Intranet应用,大部分可能都可以考虑使用AJAX
  • 基于规则的请求转发,不需要进行配置

其实,考虑这么多,主要是现在的视图层太灵活,因此代码风格以及解决问题的风格太不一致,维护起来简直是噩梦,给开发人员提供一个沙箱,他们只能在这个沙箱中发挥,那么产品整体的可维护性和一致性会大大提高。而且,开发的工作量也可以减少一倍以上,当然,搭建这个框架也需要很长时间,但是可以慢慢来,逐步的重构。

表现层是最难解决的问题

在Web开发中,表现层是最难于通用化的,个人的感觉,Tapestry是一个不错的思路,可惜学习起来并不简单,而且也需要积累才能真正的简化开发。其它的表现层框架我都不是很看好,目前我的思路倾向于使用类生成页面,和模型层绑定,这样在产品或者大型项目中可以大大的简化工作量,也减少很多问题。目前,公司的产品中虽然是使用的这种思路,但是力度不够,组件太少,和模型的绑定也不够,需要写的代码太多,一种问题在不同的地方都需要小心,搞得QA也是很不爽。
而且表现层似乎也是搞开发的人中最不喜欢做的部分,因为“技术含量太少”,基本上堆代码肯定可以搞定。虽然我也不喜欢做表现层的工作,但是必须承认,如果能够实现一个易于使用的表现层框架,对于整个项目的贡献是很大的,至少有30%的代码量,因此可以简化的工作量实际上很多。公司考虑将更多的工作转移到中国来做,希望自己有机会能够改变这个情况,让表现层的工作更加的简单。

© 2024 解惑

本主题由Anders Noren提供向上 ↑