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

wdp109 · 发表于 2006-8-8 16:38

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

apolloge · 发表于 2006-8-18 17:05

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

tigerxjtu · 发表于 2006-8-28 20:06

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

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

tigerxjtu · 发表于 2006-8-28 20:09

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

不错，我们以前的项目都是这样做的。

ytk0805 · 发表于 2006-9-17 16:35

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

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

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

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

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

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

ytk0805 · 发表于 2006-9-17 16:41

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

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

jet.han · 发表于 2006-9-19 17:41

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

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

husthxd · 发表于 2006-9-20 11:53

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

husthxd · 发表于 2006-9-20 11:55

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

justforregister · 发表于 2006-9-21 10:17

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

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

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

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

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

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

赫赫，感觉你是个做外包的，就知道在工地上干活。
没做过什么大产品。