|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-09-20
最后修改：2010-09-20
peterwei 写道 jieyuan_cg 写道 如果从GoF设计模式来说，显然集中式的controller违背了开闭原则。
如果是集中式，你每增加一个方法，都要去改变contoller的代码结构。 如果是分散式，就没有这个问题，扩展多少方法都可以支持。 Software entities should be open for extension, but closed for modification,这个就是开闭原则，你说的有一定道理。但我们不要一切唯gof是从。你说的问题在struts2及springmvc3上已经不是问题，只需简单的添加方法就行，exexute的type判断都不用了。 说说puremvc,我们项目中，我不从事flex的一线开发，不知道能不能也像springmvc3,struts2一样的通过配置文件和框架内部处理来解决type判断的问题。 以目前的情况来看，如果采用集中式，那么ApplicationFacade.as中只需注册一个CutoverCommand.as.以后修改的只是CutoverCommand.as.如果采用分开式，那么需要新添加新的Command.as,然后修改ApplicationFacade.as,添加新的注册。所以代码改动不可避免。那么我们来假设puremvc改进后，能支持不用修改ApplicationFacade.as就能动态注册新的Command.as了，type的判断自然也不会再用了。（或许puremvc已经支持，我们还没用到而已，有知道的通知一声） flex不太懂，不过，你这样设计也未偿不可。感觉，跟springmvc的contoller有相似之处。在springmvc中，你可以给某个app写一个controller，在里面处理所有的请求。但这样总感觉别扭，不利于维护。我们采用的方式就是在一个app中，每个模块有自己的controller，但模块的controller里面可以处理这个模块所有的请求方法，呵呵。这样，如果以后扩展模块，直接再新建一个controller就可以了。 其实，开闭也分粒度。controller这个层次开闭就挺好，如果在方法层面再去开闭，那可能就不合适了。 |
| 返回顶楼 | |
|
发表时间：2010-09-20
我这里是按照功能模块分开，分配到人后自己维护自己的action就好了，如果集中的话多人维护一个源码版本上会经常冲突
|
| 返回顶楼 | |
|
发表时间：2010-09-20
倾向分开，不喜欢集中。
分开 ----》 新业务增加新代码 集中-----》 新业务修改旧代码 从各方面来说，对已经稳定运行的代码越不去触及就越好。 |
| 返回顶楼 | |
|
发表时间：2010-09-20
ray_linn 写道 倾向分开，不喜欢集中。
分开 ----》 新业务增加新代码 集中-----》 新业务修改旧代码 从各方面来说，对已经稳定运行的代码越不去触及就越好。 嗯，赞成ray_linn。不过，看他们的情况，好像还不太像springmvc,struts这样的框架。每个方法都新写一个.as文件，感觉还真有点多。 |
| 返回顶楼 | |
|
发表时间：2010-09-20
最后修改：2010-09-20
抽象不变与变化的, 分离变化.
不变的是你的调用控制. 变化的是具体的业务调用. 做到对扩展开放,对修改关闭. 这个你懂的. |
| 返回顶楼 | |
|
发表时间：2010-09-20
集中也好，分布也好，没有固定的模式，适时而用，用到恰如其分是最好的
|
| 返回顶楼 | |
|
发表时间：2010-09-20
和楼主的意见一致，集中一个更好。至于，分页为何与这个有关，没仔细看，分页原理无非是数据加page信息，无论在哪里，都一样。分页参数少不了！
|
| 返回顶楼 | |
|
发表时间：2010-09-20
最后修改：2010-09-20
jieyuan_cg 写道 peterwei 写道 jieyuan_cg 写道 如果从GoF设计模式来说，显然集中式的controller违背了开闭原则。
如果是集中式，你每增加一个方法，都要去改变contoller的代码结构。 如果是分散式，就没有这个问题，扩展多少方法都可以支持。 Software entities should be open for extension, but closed for modification,这个就是开闭原则，你说的有一定道理。但我们不要一切唯gof是从。你说的问题在struts2及springmvc3上已经不是问题，只需简单的添加方法就行，exexute的type判断都不用了。 说说puremvc,我们项目中，我不从事flex的一线开发，不知道能不能也像springmvc3,struts2一样的通过配置文件和框架内部处理来解决type判断的问题。 以目前的情况来看，如果采用集中式，那么ApplicationFacade.as中只需注册一个CutoverCommand.as.以后修改的只是CutoverCommand.as.如果采用分开式，那么需要新添加新的Command.as,然后修改ApplicationFacade.as,添加新的注册。所以代码改动不可避免。那么我们来假设puremvc改进后，能支持不用修改ApplicationFacade.as就能动态注册新的Command.as了，type的判断自然也不会再用了。（或许puremvc已经支持，我们还没用到而已，有知道的通知一声） flex不太懂，不过，你这样设计也未偿不可。感觉，跟springmvc的contoller有相似之处。在springmvc中，你可以给某个app写一个controller，在里面处理所有的请求。但这样总感觉别扭，不利于维护。我们采用的方式就是在一个app中，每个模块有自己的controller，但模块的controller里面可以处理这个模块所有的请求方法，呵呵。这样，如果以后扩展模块，直接再新建一个controller就可以了。 其实，开闭也分粒度。controller这个层次开闭就挺好，如果在方法层面再去开闭，那可能就不合适了。 你没看仔细，我俩的用法其实是一样的。我说的集中式，并不指整个应用的集中式(我们当然不去做框架应该做的事情,像strtus2框架，肯定是整个应用有一个集中式的分发Controller的)，而是针对特定的业务，也就是你说的模块，复杂的模块的话，可能还再细分不同的controller.我指的分开式设计，就是你指的方法级别的，我认为是不必要的，你也持这样的观点。 如这样： UserController.java,CutoverController.java,OtherBizController.java |
| 返回顶楼 | |
|
发表时间：2010-09-20
soci 写道 我这里是按照功能模块分开，分配到人后自己维护自己的action就好了，如果集中的话多人维护一个源码版本上会经常冲突
你也没看仔细。 |
| 返回顶楼 | |
|
发表时间：2010-09-20
webee 写道 和楼主的意见一致，集中一个更好。至于，分页为何与这个有关，没仔细看，分页原理无非是数据加page信息，无论在哪里，都一样。分页参数少不了！
分页只是引子，和本主题没有必然联系。 |
| 返回顶楼 | |
