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

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

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

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

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

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

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

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

这边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的参数传过去，，无论是我的做法还是我们经理的做法都是传这样的数据。

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

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

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

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