求救,什么技术可以减少jsp中代码量

最近我们系统想做升级,业务的逻辑比较复杂,以前用的是jsp,但是越往后开发越觉得jsp代码量太大了,而且逻辑不清晰,到后期可以说是有臭又硬,请各位有经验的前辈指教一下,用什么框架和技术能够比较好的来弥补这个缺点,主要是想解决页面上控件之间相互控制的太多,请各位高手建议一些方案和用这种方案的原因,跪谢.

jsp页面原本应该只是进行显示作用以及与后台交互数据用的，大量的java代码应该放到bean或者servlet里面，另外可以考虑很多开源框架，例如struts，webwork，spring等等。当然前提是你必须熟练使用这些框架，否则会导致开发效率降低。至于你现在这个系统，把原本jsp里面的代码提炼到bean，由bean来完成业务逻辑处理，jsp调用javabean来实现业务处理结果显示。

[QUOTE][i]最初由 Dennis68cn 发布[/i]
[B]jsp页面原本应该只是进行显示作用以及与后台交互数据用的，大量的java代码应该放到bean或者servlet里面，另外可以考虑很多开源框架，例如struts，webwork，spring等等。当然前提是你必须熟练使用这些框架，否则会导致开发效率降低。至于你现在这个系统，把原本jsp里面的代码提炼到bean，由bean来完成业务逻辑处理，jsp调用javabean来实现业务处理结果显示。 [/B][/QUOTE]

受教受教，多谢多谢:rose:

应该学点web框架. struts＆webwork都型

我们开发用过structs ,现在正在研究webwork,但是页面上得逻辑太复杂,如果都写在会话bean中势必会导致效率得地下吧.首先还是感谢指教,我们准备框架用webwork,底层用hibrnate,页面部分用ajax技术,直接连数据库,不知道这样以来是不是会使框架更加难以控制,请指教

不错

[QUOTE][i]最初由 liubaojun 发布[/i]
[B]我们开发用过structs ,现在正在研究webwork,但是页面上得逻辑太复杂,如果都写在会话bean中势必会导致效率得地下吧.首先还是感谢指教,我们准备框架用webwork,底层用hibrnate,页面部分用ajax技术,直接连数据库,不知道这样以来是不是会使框架更加难以控制,请指教 [/B][/QUOTE]

JAVA已经对JSP页面调用Java Bean做过优化了.基本可以忽略不记算.你可以上网查查.记得书上这样讲过

[QUOTE][i]最初由 ever1999861 发布[/i]
[B]

JAVA已经对JSP页面调用Java Bean做过优化了.基本可以忽略不记算.你可以上网查查.记得书上这样讲过 [/B][/QUOTE]:right: :right:

哈哈.楼上的那位老大.你JSP和J2EE技术很厉害吧.
能否有时间和小弟我交流下?
小弟我愿拜你为师.虚心学习
我喜欢技术!

高手真多,.,

高手云集的地方,俺来学点.

struts是个不错的选择，前台和逻辑处理完全分开，接上spring，干净分明，便于维护管理，新机能可以以插件的方式添加，不会对原有模块造成任何影响！

[QUOTE][i]最初由 liubaojun 发布[/i]
[B]我们开发用过structs ,现在正在研究webwork,但是页面上得逻辑太复杂,如果都写在会话bean中势必会导致效率得地下吧.首先还是感谢指教,我们准备框架用webwork,底层用hibrnate,页面部分用ajax技术,直接连数据库,不知道这样以来是不是会使框架更加难以控制,请指教 [/B][/QUOTE]

逻辑写在Java Bean中，不是会话Bean。
这种方式的目点无非是让JSP中出现的Java代码很少，对效率不会产生太大的影响。

[QUOTE][i]最初由 Dennis68cn 发布[/i]
[B]jsp页面原本应该只是进行显示作用以及与后台交互数据用的，大量的java代码应该放到bean或者servlet里面，另外可以考虑很多开源框架，例如struts，webwork，spring等等。当然前提是你必须熟练使用这些框架，否则会导致开发效率降低。至于你现在这个系统，把原本jsp里面的代码提炼到bean，由bean来完成业务逻辑处理，jsp调用javabean来实现业务处理结果显示。 [/B][/QUOTE]
不错，我们以前的项目都是这样做的。

真正业务效益高的网络应用公司，他们的前台应用都不会考虑用什么框架和持久层这种无无聊聊的东东，因为它们严重地影响了工作的效率，导致了业务的效益低下！！！

前台，他们都是直接用JSP+JAVABEAN+SERVLET。

所谓的框架：其实就是将设计者的工作量推给了程序员，将后来接手人的工作量推给了前度负责人罢了。

对于网络应用，业务需求时刻变化，什么烂框架什么烂持久层，你们认为它们真的可以为你带来什么升级方便吗？呵呵，完全没有。如果有的话，那只是因为你的业务需求变更只是很少很少的变动而已。当业务需求真正发生180度变化时，你就会恨不得将什么框架什么持久层一一粉碎，你会疯了的！

那什么样的情况才适合用框架和持久层呢？
那是做后台的情况下！因为那是前台的业务变更对后台的影响非常少的。

还有什么设计模式，我操！都是无无聊聊的人搞出来的东西，设计模式是需要用心来体会的，不是用来照搬的。设计模式应该是学术式的探讨，不应该过多地渗透到实际应用中

再追加几句：
所谓的框架和持久层，或许是JAVA越来越让人讨厌而越来越不受欢迎的原因吧，都在无无聊聊地瞎搞，这个家伙想出了什么以为好的东东就胡乱地给JAVA加上去，那个家伙想出了什么以为好的点子也胡乱地给JAVA加上去，我操。

例如那个 所谓用于取代JSP的技术：VELOCITY
我操，垃圾！！！不但取代不了，更是增添了不少麻烦。傻仔才会考虑用它的吧！

我们的开发框架采用 sitemesh + struts +hibernate ,sitemesh尽量把页面的显示和form分离开来，使得页面上大部分的代码比较简单。

对框架而言，我认为其实没有什么好还，关键是能否满足需求。

前台页面能够完成获取输入数据/显示输出数据即可,业务处理逻辑一般通过后台javabean去实现.
个人认为,不管开发什么j2ee应用,Facade模式是一定要使用到的.
如果想用b/s方式开发复杂的系统,高效的前台开发是不用jsp:
1.纯htmp/js/ajax,开发通用的控件,重用代码
2.前台用.net,中间层用j2ee,这种只是一种想法,目前还没有资源去尝试.

btw:
技术无所谓好坏,关键是要找到适合该技术应用的领域.
没有了解清楚就说这个技术不好,那个架构不行是不太负责任的.

[QUOTE][i]最初由 ytk0805 发布[/i]
[B]真正业务效益高的网络应用公司，他们的前台应用都不会考虑用什么框架和持久层这种无无聊聊的东东，因为它们严重地影响了工作的效率，导致了业务的效益低下！！！

前台，他们都是直接用JSP+JAVABEAN+SERVLET。

所谓的框架：其实就是将设计者的工作量推给了程序员，将后来接手人的工作量推给了前度负责人罢了。

对于网络应用，业务需求时刻变化，什么烂框架什么烂持久层，你们认为它们真的可以为你带来什么升级方便吗？呵呵，完全没有。如果有的话，那只是因为你的业务需求变更只是很少很少的变动而已。当业务需求真正发生180度变化时，你就会恨不得将什么框架什么持久层一一粉碎，你会疯了的！

那什么样的情况才适合用框架和持久层呢？
那是做后台的情况下！因为那是前台的业务变更对后台的影响非常少的。

还有什么设计模式，我操！都是无无聊聊的人搞出来的东西，设计模式是需要用心来体会的，不是用来照搬的。设计模式应该是学术式的探讨，不应该过多地渗透到实际应用中 [/B][/QUOTE]
赫赫，感觉你是个做外包的，就知道在工地上干活。
没做过什么大产品。