01月02, 2012

侵入式前端框架设想

是从gui说起还是从鼠标键盘说起呢。

总之,界面上的元素,及这些元素对鼠标和键盘动作做出的反馈,,由此开始了一个事件处理的流程。

而事件处理函数里,,是不该包含业务知识的吧,因为这是UI层,,UI层及事件的职责,,仅仅是负责UI的绘制,调整,当然在浏览器dhtml编程中通过操纵dom来实现,但这不重要,,重要的是UI层只做这些工作。。于是,我们有了一个UI类,,可以把jQuery包含进来,作为操纵dom的工具。 然后呢,是下面,下面是应用层,应用层应该能看到业务术语了吧?等等,当然不应该,那么应用层应该做什么呢。。事务,任务进度,事件同步,信号量,互斥体,自旋锁??嗯,,是不是把这些概念塞在这里呢、、

然后是什么,业务层,,业务层,包含什么? 有状态的对象,无状态的service,还有业务实体entity。

那么下面是什么,基础设施层,,基础设施层做什么?向上面3层提供支持,,当然不是只向业务层提供支持。

对业务层提供的支持是数据的持久化,,在这里,从UI的FORM,到应用层辅助处理,,然后到业务层成为一个entiy,,最终通过业务层对基础设施层的调用,,将这个entity持久化??怎么持久化??序列化并存到服务器吧,持久化只是一个接口,,可以有AJAX实现,也可以有local-storage的实现,,是异步式的。

等等,最重要的是什么??基础设施层最重要的不是提供这些service,而是向上层提供了rule。

如何提供,,典型的做法就是截获所有入口并自己来做dispathcher分发,,具体怎么做,,两条路:

1 由类名和方法名,来映射元素及事件名,对类名和方法名进行解析,并绑定到dom上。

2 反向,先拿到事件相关的所有信息,然后通过事件所在的dom节点和事件类型等所有信息,,再检索类,,调用相关类的方法。

第一种当然是有优点的噢,性能不会有任何问题,,但缺点是动态引入新的类,,要重新解析类名和方法名映射到dom上

第二种呢,,缺点是每个事件都要进行封装,先解析事件信息,根据事件信息去检索类,,增加了一些性能上的开销。。

不过这种rule是必须的,,因为js程序日益复杂,,必须从底层对上层做出许多编码级的强约定。

本文链接:https://75team.com/post/侵入式前端框架设想.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。