精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2011-08-02
ltian 写道 居然还有人用PureMVC!
用啥框架比较给力 ?? |
|
返回顶楼 | |
发表时间:2011-08-03
dsjt 写道 ltian 写道 居然还有人用PureMVC!
用啥框架比较给力 ?? 其实他也不懂 |
|
返回顶楼 | |
发表时间:2011-08-03
还没有用过puremvc,要好好学习一下了
|
|
返回顶楼 | |
发表时间:2011-08-04
testfor1 写道 dsjt 写道 ltian 写道 居然还有人用PureMVC!
用啥框架比较给力 ?? 其实他也不懂 我承认你真懂,你说说你懂的道理吧。 |
|
返回顶楼 | |
发表时间:2011-08-04
dsjt 写道 ltian 写道 居然还有人用PureMVC!
用啥框架比较给力 ?? 基于消息解耦的框架都不要轻易用,尤其是当项目稍大的时候,这时候如果管理不善,可能会造成消息或者事件名称的冲突,同时,不同人对消息根据自己的理解做了不恰当的监听,就会导致莫名奇妙的怪异现象发生,而且难以调试。PureMvc 的源代码我读过,Cairnorm的我也读过,代码行数不多,很容易理解,下面请上面懂的那位谈谈,可能有不同的见解,我这只是个人的项目吃过亏,也许我用的不好,对PureMVC认识的不够深刻。 我认为Flex开发,可以根据需要采用一些面向专业领域的框架,比如:专门用于图形开发组件库,或者用于地图开发的组件库,通用的,面面俱到的基本不太可用。 |
|
返回顶楼 | |
发表时间:2011-08-05
只能说现在好多人觉得离开框架的约束自己就没信心写出规范的代码,其实我也有一点这种感觉,但是真的有必要在Flex这一层做MVC吗?非常搞的是,现在ExtJS也弄了个MVC,有必要吗。。。。。。真的有必要吗?
|
|
返回顶楼 | |
发表时间:2011-08-06
andy_ghg 写道 只能说现在好多人觉得离开框架的约束自己就没信心写出规范的代码,其实我也有一点这种感觉,但是真的有必要在Flex这一层做MVC吗?非常搞的是,现在ExtJS也弄了个MVC,有必要吗。。。。。。真的有必要吗?
①一个mxml文件包括<script>和页面标签等,初级程序员会把所有的actionscript代码写在<script>标签内,如果一页页面业务量过大,script可能上千行,一个页面密密麻麻的代码,维护起来眼睛都会花,而对于一个美工来说,要在万码丛中修改某些标签样式是多么困难的事--因为他不知道他的修改是否会影响到as代码。 ②懂得面相对象,解耦合的程序员会根据不同功能创建不同Actionscript类,这样mxml中的<script>会极大减少,维护起来也不会太头疼。但是,一个项目不是一个程序员在干,多个程序员同时开发的话,没有特定规则限定,编码习惯、命名习惯差异,导致项目包混乱,这样对后面维护的人员依然会造成极大困扰。 ③几个人聚在一起,决定定义一些规则,比如报表的代码放在报表包里,用户注册类放在用户包里,这样各个模块减少耦合度,代码可读性明显增强。但是又有一些问题:事件代码和远程调用获取数据的代码混在同一类中,很多操作本来可以复用的,但是因为写在一个类中,其它类也不能随便访问,这样导致很多地方出现了不必要的重复代码,假如一处修改,其它也得跟着改,有时候可能漏掉一个,这种隐藏过深的bug让人很棘手。 ④于是大家又商量起来:把页面事件抽离出来,专门用一种模型处理事件;所有事件中的逻辑操作,以及模块切换又抽离出来使用另一种模型处理;最后获取数据、远程调用再抽离出来,这样就能达到层层解耦,逻辑清晰,代码复用,维护行高的效果。这就是MVC。 都说php运行快,开发也快,但是缺点就是可重用性和可维护性,因为很多脚本与标签混为一体。 如果用这种方式开发flex,一个人的话没多大问题,但是如果是一个团队商业项目,没有一种规则,试想等项目结束到维护期以后,谁愿意去看别人的代码? mvc定义了一种规范,一种前人从千万次失败中总结出来的成功的规范,这种东西是很值得我们借鉴的。 |
|
返回顶楼 | |
发表时间:2011-08-07
白糖_ 写道 andy_ghg 写道 只能说现在好多人觉得离开框架的约束自己就没信心写出规范的代码,其实我也有一点这种感觉,但是真的有必要在Flex这一层做MVC吗?非常搞的是,现在ExtJS也弄了个MVC,有必要吗。。。。。。真的有必要吗?
①一个mxml文件包括<script>和页面标签等,初级程序员会把所有的actionscript代码写在<script>标签内,如果一页页面业务量过大,script可能上千行,一个页面密密麻麻的代码,维护起来眼睛都会花,而对于一个美工来说,要在万码丛中修改某些标签样式是多么困难的事--因为他不知道他的修改是否会影响到as代码。 ②懂得面相对象,解耦合的程序员会根据不同功能创建不同Actionscript类,这样mxml中的<script>会极大减少,维护起来也不会太头疼。但是,一个项目不是一个程序员在干,多个程序员同时开发的话,没有特定规则限定,编码习惯、命名习惯差异,导致项目包混乱,这样对后面维护的人员依然会造成极大困扰。 ③几个人聚在一起,决定定义一些规则,比如报表的代码放在报表包里,用户注册类放在用户包里,这样各个模块减少耦合度,代码可读性明显增强。但是又有一些问题:事件代码和远程调用获取数据的代码混在同一类中,很多操作本来可以复用的,但是因为写在一个类中,其它类也不能随便访问,这样导致很多地方出现了不必要的重复代码,假如一处修改,其它也得跟着改,有时候可能漏掉一个,这种隐藏过深的bug让人很棘手。 ④于是大家又商量起来:把页面事件抽离出来,专门用一种模型处理事件;所有事件中的逻辑操作,以及模块切换又抽离出来使用另一种模型处理;最后获取数据、远程调用再抽离出来,这样就能达到层层解耦,逻辑清晰,代码复用,维护行高的效果。这就是MVC。 都说php运行快,开发也快,但是缺点就是可重用性和可维护性,因为很多脚本与标签混为一体。 如果用这种方式开发flex,一个人的话没多大问题,但是如果是一个团队商业项目,没有一种规则,试想等项目结束到维护期以后,谁愿意去看别人的代码? mvc定义了一种规范,一种前人从千万次失败中总结出来的成功的规范,这种东西是很值得我们借鉴的。 说的太长太罗嗦了,MVC的最为精髓的地方就是视图与模型的分离,说白了是一种分层而已。但是PureMVC这个框架和MVC思想不是一回事。 |
|
返回顶楼 | |