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

总共有 14 回复／ 1 页

vegetable318

悄悄话
发表文章: 13
注册时间: 2004年07月02日 11:02

各位大虾帮忙，bangq大哥过来帮帮忙了	2004年08月10日 11:41
标签列表案例经验(47) 多层架构(34)

小弟现在做的项目，用的是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

悄悄话
发表文章: 13
注册时间: 2004年07月02日 11:02

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月10日 14:25

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

zingers

悄悄话
发表文章: 178
注册时间: 2002年08月14日 16:11

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月10日 14:53

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

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

banq

悄悄话
发表文章: 9484
注册时间: 2002年08月03日 17:08

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月10日 15:34

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

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

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

banq

悄悄话
发表文章: 9484
注册时间: 2002年08月03日 17:08

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

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都无影响。

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

vegetable318

悄悄话
发表文章: 13
注册时间: 2004年07月02日 11:02

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月10日 15:58

public UserResultBean registerWEBCCInDomain(Object[] beanargs)
{
Domainreg domainreg =(Domainreg)beanargs[0];
Productorder porder=(Productorder)beanargs[1];
Nsiuserinfo nsiuifreg=(Nsiuserinfo)beanargs[2];
Nsiuserinfo nsiuifadmin=(Nsiuserinfo)beanargs[3];
Nsiuserinfo nsiuiftech=(Nsiuserinfo)beanargs[4];
Nsiuserinfo nsiuifbill=(Nsiuserinfo)beanargs[5];
Funddetail funddetail=(Funddetail)beanargs[6];
Dnsregister dns1=(Dnsregister)beanargs[7];
Dnsregister dns2=(Dnsregister)beanargs[8];

这边dns1的某些熟悉值必须从数据库表中来，
dns1.setIp("数据库中的值");
dns2.setIp("数据库中的值");
//dao封装了所有单表的操作
dao.insert(domainreg);
dao.insert(porder);
dao.insert(nsinuifreg);
........
}

这个就是delegate中业务函数的简化，我的做法就是这些所有的javabean都是再command中实现
{
//查询数据库
dns1.setIp("数据库数据")；
dns2.setIp("数据库数据");

//生成所有的javabean

Domainreg domainreg =new Domainreg();
Productorder productorder =new Productorder();
Dns1 dns1 = new Dns1();
Dns2 dns2 =new Dns2();
Nsiuserinfo nsiuifreg =new Nsiuserinfo();
Nsiuserinfo nsiuifadmin =new Nsiuserinfo();
Nsiuserinfo nsiusertech = new Nsiuserinfo();
Nsiuserinfo nsiuserbill =new Nsiuserinfo();

//所有javabean的赋值
每个bean都有大量的属性值
......其中有数据库中取到的值，有jsp表单的值,还有固定的比如日期的赋值等操作。
//查询数据库
dns1.setIp("数据库数据")；
dns2.setIp("数据库数据");

Object[] args={javabeans};
delegate.registerWEBCCInDomain(args);
}

我们经理的做法：
command:
{
Domainreg domainreg =new Domainreg();
domainreg.setDomainname("jsp表单值");
//只赋值表表单的值，
}

他在delegate中写我在command中的赋值操作，，现在的矛盾就是在javabean的赋值写在什么地方，我们没有用EJB，但是用设计模式多层操作来业务分层，command调用delegate的只是把javabean的参数传过去，，无论是我的做法还是我们经理的做法都是传这样的数据。

我的做法可能要多跟数据库交互一次，因为要赋值，，而且主要是每个函数的业务操作比较复杂，，现在有点不明白这个赋值的操作到底是业务的操作，还是别的。。

vegetable318

悄悄话
发表文章: 13
注册时间: 2004年07月02日 11:02

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月10日 16:19

谢谢banq大哥的回复，但是有一点，我的做法是多一次或者两次的数据库查询，但是我们经理的做法是把javabean的赋值分开了，，我做的统一一些，他考虑到效率，，最主要是在这次通讯的开销上，还有对系统以后的维护问题，，或许我想的折中的办法，就是在后面只做需要查询数据库数据的属性赋值，其余的都在command中生成javabean，其实这样应该是跟接近我们经理的做法吧，也不用进行额外的通讯。MY GOD ,庞大的代码修改！

banq

悄悄话
发表文章: 9484
注册时间: 2002年08月03日 17:08

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月11日 11:29

>我们经理的做法：
>command:
>{
>Domainreg domainreg =new Domainreg();
>domainreg.setDomainname("jsp表单值");
>//只赋值表表单的值，
>}

在command中只处理表单的值，应该是这样。
你的beanargs[]其实就是DTO，专门用来建立Web前端和后端数据传递。
如果beanargs[]打包涉及数据库操作，当然不能在Web的command中完成。

我感觉整个系统很乱，主要没有从面向对象设计入手，没有清晰可见的Model，建议读读Petstore中的Model相关类。

glassprogrammer

悄悄话
发表文章: 3
注册时间: 2004年03月05日 12:50

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月18日 09:33

我觉得你们经理的观点比较正确, Web层需要尽量简单, 只应该完成把页面传递过来的数据收集之后, 传递到业务逻辑层中处理这样一个任务.

其实严格来说, Web层 --> 业务逻辑层所使用的JavaBean(DTO) 和业务逻辑层 --> 数据库层使用的DTO 是不一致的, 前者是页面上数据的映射(其实还包括一些Web层的其它东西, 比如session中的数据), 后者表示数据库(业务模型)中的数据, 你们的设计中把这两个东西混为一谈, 也是产生你这种观点的一个原因.

hgwnet

悄悄话
发表文章: 134
注册时间: 2003年01月05日 14:36

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月18日 18:41

比较支持你经理的做法。
当你在经历过几个比较复杂的项目后，你会发现在web层若也处理业务逻辑，不但会造成业务处理的混乱，而且还会破坏你们的设计模式。一旦对模式造成了冲击，最后你不得不花大力气来对系统进行重新架构。

youngS

悄悄话
发表文章: 38
注册时间: 2004年03月26日 00:03

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月24日 17:05

我觉得问题的重点在于，你和你的经理之间的职责已经混乱了。其实不管设计模式是什么样的，只要整个系统的架构都是一个人来控制的，这种设计上的内部矛盾应该是可以减少到一个合理的、可以接收的程度的。现在很明显的一个现象是，你和你的经理看来起来都像是系统架构设计者，但是对一个项目来说，应该只有一个架构设计者。你这个问题从根本上来说不是技术上的问题，而是项目管理和安排上的问题。

youngS

悄悄话
发表文章: 38
注册时间: 2004年03月26日 00:03

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年08月24日 17:09

这里这么多人纷纷从技术上给你建议，我个人认为这只会导致你在今后的项目中更多的迷茫。更有效的建议在我看来是分清你和你经理的职责，两个人的工作不要混淆在一起，让你们的工作性质不要纠缠不清。这样做也许才是这个问题的根本解决办法。

nicoh

悄悄话
发表文章: 1
注册时间: 2004年08月27日 18:19

路过，也说一句

2004年08月27日 18:23

同意楼上的，职责要分清。无论怎样做，都能实现功能，分别只是性能好坏的问题。但是一旦不统一就会有很多问题。深有体会，虽然自己水平很低……

新新低手

悄悄话
发表文章: 1
注册时间: 2004年08月31日 13:30

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年09月02日 15:53

看了各位大大滴评论，深受启发，嘿嘿

vegetable318

悄悄话
发表文章: 13
注册时间: 2004年07月02日 11:02

Re: 各位大虾帮忙，bangq大哥过来帮帮忙了

2004年09月08日 17:53

没有想到这么久了还有这么多人回复,,呵呵,,其实项目的框架是我做的,,征求我们经理的意见以后我就开始做了,只是当时在做框架的时候还没有思考到这么细节的东西,,以后一定要吸取教训!呵呵,可惜俺都辞职了!

这个主题有 14 回复／ 1 页