各位大虾帮忙,bangq大哥过来帮帮忙了

04-08-10 vegetable318
         

小弟现在做的项目,用的是mvc模式,现在在web这端,用command模式处理接受表单的数据,调用 业务逻辑端delegate的业务处理,现在遇到一个比较模糊的问题:在command端我传送的是javabean到delegate端,进行业务操作,我的做法是先生成所有要操作到的javabean,这样在业务端的操作,我只要用这些javabean进行业务的操作,比如写库表,修改库表,当然对于一些少修改字段的库表,直接在delegate的业务端生成对应的javabean,进行数据库操作,以及业务逻辑的交互,(因为我对于业务逻辑操作的理解是对这些总体javabean的操作,不包括对于某个javabean某个域值的赋值,但是因为业务操作的复杂性,使得某些javabean的赋值是比较复杂的)这样问题就出来了:1.这种javabean赋值是否属于逻辑的操作?,如果是,是否就应该放置在业务逻辑这端比较好呢?

我们经理的做法是,在command只接受表单的数据,他只生成表单接受到的数据的javabean,这样在业务逻辑端他对这样不完整的javabean进行大部分的赋值,当然,有些javabean的数据必须是从数据库对应的相关表中取值的,甚至在业务逻辑这端生成几个javabean,然后进行一样的业务操作,库表操作等,他的理解是对javabean赋值的操作因为有很大的复杂性,也属于业务逻辑的操作,这样操作的好处是使得web端比较简洁,但是业务逻辑端就有非常多的javabean赋值的操作,而且这样做的好处是只和数据库通讯一次,而我的做法,可能因为要生成完整的javabean传给业务逻辑端,所以要进行两次,或者三次的通讯,这样方法的操作类似stateless session bean的业务逻辑方法,我们的数据量一般都在百万级以上,现在的我们经理建议的是减少通讯次数,而我的做法是感觉我们经理的做法把javabean的赋值都分开了,比较乱,不够简明。而且业务逻辑这样比较不明确,现在我做的部分都差不多已经调试快结束,如果采用我们经理的方法,我所有的代码都要进行,修改,现在想采用的折中的方法,就是还是生成完整的javabean,但是在业务逻辑操作修改javabean的值,这样虽然也有赋值的语句,但是只是修改,而不会有完全在业务逻辑端生成完整javabean的情况,减少业务逻辑的复杂性,也可以只通讯一次,同时减少代码的修改量,不知道各位大虾能否有什么更好的办法,还有我所提出的问题 :1.这种javabean赋值是否属于逻辑的操作?,如果是,是否就应该放置在业务逻辑这端比较好呢?,谢谢各位大虾了。

         

vegetable318
2004-08-10 14:25

banq大哥不在吗,,能否指点一二,谢谢了。。。

zingers
2004-08-10 14:53

你不贴一点代码或则伪代码是很难说明问题的

个人感觉你们经理从性能出发考虑是实际的。

banq
2004-08-10 15:34

>javabean赋值是否属于逻辑
在纯JavaBeans体系中,javabean赋值赋值分两种:
1. jsp页面form表单赋值到Javabeans中。
2. JavaBeans赋值到数据库。

你讲的通讯是指Web层和业务层吗?因为你的业务层也是用JavaBeans,不是EJB,通讯次数对性能有影响吗?

还有一种JavaBeans作为DTO,数据传送的,需要不断地new,一般对性能影响不大。

banq
2004-08-10 15:43

>1.这种javabean赋值是否属于逻辑的操作?,如果是,是否就应该放置在业务逻辑这端比较好呢?

大部分属于,我看你和经理的争论焦点是JavaBeans的归类问题,这个问题如果引入一个架构框架,如Struts + EJB/Struts + JdonSD/Spring等之类框架就不会了。

总的来说,处理Jsp相关的JavaBeans属于Web层(包括页面控制跳转),还有传递数据的DTO的JavaBeans,其他所有JavaBeans基本属于逻辑业务层。
不要在Web层的JavaBeans中做过多事情,Web层中javaBeans只是将前台Form数据打包成DTO,委托给业务层具体做。

因此,这其中难免发生多次通讯的问题,因为Web层在对数据组织方面基本是“傻瓜“,使用Local性质的SLSB和普通JavaBean都无影响。

我认为你们两个做法没有好坏之分,特别是你,没有必要重新做。不知我理解得对否?


3Go 1 2 3 下一页