论坛首页 Java企业应用论坛

“过度设计”之真实例子

浏览 85190 次
该帖已经被评为新手帖
作者 正文
   发表时间:2010-09-30  
Durian 写道
徐风子 写道
设计:一定要写过代码的人做。

----------
顶你这话。

++
0 请登录后投票
   发表时间:2010-09-30  
引用
页面是不需要写HTML代码的,所以helloWorld.js直接可以省掉,直接把js写在jsp文件里

写在js文件里就可以考虑采用缓存(Cache-Control),不用每次加载都发送一次http请求。而直接写在jsp里面虽然也省了请求,但每次都得重新下载一次。另外,如果js文件比较大的话,分出来维护成本明显会降低,至少有功能强大的js编辑器作为支持,但同时把jsp和js都支持得很好的还没见过。
0 请登录后投票
   发表时间:2010-09-30  
hyj1254 写道
引用
页面是不需要写HTML代码的,所以helloWorld.js直接可以省掉,直接把js写在jsp文件里

写在js文件里就可以考虑采用缓存(Cache-Control),不用每次加载都发送一次http请求。而直接写在jsp里面虽然也省了请求,但每次都得重新下载一次。另外,如果js文件比较大的话,分出来维护成本明显会降低,至少有功能强大的js编辑器作为支持,但同时把jsp和js都支持得很好的还没见过。


写在JSP的js其实就是本页面的业务代码, 如果是写组件或控件或公共业务代码,肯定是分出来
0 请登录后投票
   发表时间:2010-09-30  
如果就做简单的“增、删、改、查”的话,你们用SSI做什么??有必要吗?
Struts2里面的Action具体看成Controller还是Model也不是绝对的吧。

学我者生,象我者死。

LZ,你太教条啦。
0 请登录后投票
   发表时间:2010-09-30  
lpn520 写道
hyj1254 写道
引用
页面是不需要写HTML代码的,所以helloWorld.js直接可以省掉,直接把js写在jsp文件里

写在js文件里就可以考虑采用缓存(Cache-Control),不用每次加载都发送一次http请求。而直接写在jsp里面虽然也省了请求,但每次都得重新下载一次。另外,如果js文件比较大的话,分出来维护成本明显会降低,至少有功能强大的js编辑器作为支持,但同时把jsp和js都支持得很好的还没见过。


写在JSP的js其实就是本页面的业务代码, 如果是写组件或控件或公共业务代码,肯定是分出来



Extjs中的JS是负责展示的,你用来写业务代码????
0 请登录后投票
   发表时间:2010-09-30  
zdmcjm 写道
别争了,都来用grails吧,正常人用过grails后,都不会再想用java开发所谓的企业级应用了。

的确是这样,grails有很多我所希望的东西,不过就是有点缺陷,修改了代码后需要等待很久才能重新热部署完成。同时期待groovy++。

作为架构师我觉得楼主提出这个问题是很正常的,也是很必要的,有些东西的确是不破不立。这个只有根据实际情况来定夺。

架构本来就是根据实际情况不断发展、不断变化的,性能优先、团队协同优先、开发效率优先这些在不同的情况下面都应该有不同的侧重,当然还有很多影响架构的因素:人员配置情况、人员对开发框架的认同度和了解情况、需求变化频度等,所以根据实际情况来进行选择和变化是必要的。
0 请登录后投票
   发表时间:2010-09-30   最后修改:2010-09-30
t42dw 写道
lz有没有想过,有一天你的业务逻辑变了你需要改动多少代码,有一天你不用spring MVC了你需要改动多少,有一天你所用的数据库变了或者不用ibatis你需要改动多少代码?

当然我说的这些可能以后都不会发生,但没办法我们不是神不知道以后会发生什么只能提前预防。

当然我们也可以不考虑这些可能不会发生的事,不过你有没有想过有一天真的需要变动那个开发变动版本兄弟对你的漫骂

控制,业务,数据操作分开还是很有道理的


分开当然要分开,Model-View-Controllor三层,再加上DAO一层,总共四层
Model                     就是 Action
View                      就是 JSP
Controllor                struts2已经实现了,不需要你实现
DAO                       ibatis已经实现了,你要做的就是在sqlmap.xml里写SQL就行了

你觉得这四层不够应变你所说的业务逻辑变更吗? 我想问,你业务逻辑变更了,难道真能可以只修改一层,其它层都不用修改吗?

0 请登录后投票
   发表时间:2010-09-30   最后修改:2010-09-30
pengjj2 写道
这个很正常,按楼主的说法,如果硬要把前端页面也算一层的话,也顶多四层而已。
参照mvc模型,你这个结构顶多多了一个服务层。
要有8个文件主要是多了service的接口,和dao的接口。
面向借口编程我想没有什么可以诟病的。

如果仅仅说服务端的话,这是一个很正常的三层设计模式。
action用来做控制转发是有必要的。有些复杂的逻辑如果你写在action里面,同样会导致可读性的问题。
action不仅仅是控制转发,有时候还会承担一些数据的处理工作。
service层仅仅用来做业务逻辑是很合理的。

js单独放文件时很有必要的,项目的后期维护,如果团队更换或人员更换,在html里的js会导致可读性很差。
当然也要保证你的js文件结构合理,功能分类比较合理。

封装ext,或者封装jquery我也认为没有道理,我觉得国内的编码人员很难达到人家的水平,也许封装只是导致更多问题的出现而已。

如果你们的项目如果是小型项目的话我想简化设计是可以的,如果你的项目要不断扩展和维护,你的简化会导致很多后期问题。

这个结构我可以很明确的告诉你,华为几千万美金的电信项目,结构分层和这个差不多,甚至多出一到二层。
项目分层而言,我觉得这个很正常,但是具体情况要看你们具体的项目情况,别一棍子把人打死了。


华为WEB开发一直使用7层方式,要是LZ来做华为WEB项目怕是会疯掉

当然所用技术有所不同这边WE以经开始普及华为自主开发的jalor框架了,其实也就是struts+EJB+ibatis
0 请登录后投票
   发表时间:2010-09-30  
liupopo 写道
lpn520 写道
hyj1254 写道
引用
页面是不需要写HTML代码的,所以helloWorld.js直接可以省掉,直接把js写在jsp文件里

写在js文件里就可以考虑采用缓存(Cache-Control),不用每次加载都发送一次http请求。而直接写在jsp里面虽然也省了请求,但每次都得重新下载一次。另外,如果js文件比较大的话,分出来维护成本明显会降低,至少有功能强大的js编辑器作为支持,但同时把jsp和js都支持得很好的还没见过。


写在JSP的js其实就是本页面的业务代码, 如果是写组件或控件或公共业务代码,肯定是分出来



Extjs中的JS是负责展示的,你用来写业务代码????


是用来展示的,但异步请求的驱动还是从前端上来的,界面是用户操作的接口
0 请登录后投票
   发表时间:2010-09-30  
t42dw 写道
pengjj2 写道
这个很正常,按楼主的说法,如果硬要把前端页面也算一层的话,也顶多四层而已。
参照mvc模型,你这个结构顶多多了一个服务层。
要有8个文件主要是多了service的接口,和dao的接口。
面向借口编程我想没有什么可以诟病的。

如果仅仅说服务端的话,这是一个很正常的三层设计模式。
action用来做控制转发是有必要的。有些复杂的逻辑如果你写在action里面,同样会导致可读性的问题。
action不仅仅是控制转发,有时候还会承担一些数据的处理工作。
service层仅仅用来做业务逻辑是很合理的。

js单独放文件时很有必要的,项目的后期维护,如果团队<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>更换或人员更换,在html里的js会导致可读性很差。
当然也要保证你的js文件结构合理,功能分类比较合理。

封装ext,或者封装jquery我也认为没有道理,我觉得国内的编码人员很难达到人家的水平,也许封装只是导致更多问题的出现而已。

如果你们的项目如果是小型项目的话我想简化设计是可以的,如果你的项目要不断扩展和维护,你的简化会导致很多后期问题。

这个结构我可以很明确的告诉你,华为几千万美金的电信项目,结构分层和这个差不多,甚至多出一到二层。
项目分层而言,我觉得这个很正常,但是具体情况要看你们具体的项目情况,别一棍子把人打死了。


华为WEB开发一直使用7层方式,要是LZ来做华为WEB项目怕是会疯掉

当然所用技术有所不同这边WE以经开始普及华为版主开发的jalor框架了,其实也就是struts+EJB+ibatis


人家是宰牛,哥们我是杀鸡,谢谢
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics