不需要一个界面对应一个ejb的。将一些有共同属性的抽出来做一个ejb可能会好点
解决方案 »
- 哪位高手回答一下,我用jsp页面传值先跳到action然后用ModelDriven接受的整个对象,int行可以接受,但是为什么汉字就变成乱码了呢。。。。。。。。
- java连接数据库的问题
- Struts DownloadAction 的问题~!!文件路径~~~
- 请问哪里有JTurbo下载?
- 在struts中页面转发的问题
- 求解javamail发外网的实现
- 奇怪的问题!tomcat经常死,要让jsp文件重新编译才行。在线等!!!
- 请问高手如何自己实现ejb container中connection pooling的机制?
- 反射
- synchronize修饰一个方法时,怎么理解多个线程多个锁?是否会导致数据不安全?
- 关于容器处理jms消息的顺序的问题(高手请进)
- 菜鸟提问~~~~有关import的问题
EJB可是重量级的
呵呵,我想问问,如果象你说的那要怎样来实现,不觉得这样更容易挤对?
这样对前面的servlet更加添加负担
个人意见
我以前做的那个项目性质和你的一样。仔细考虑了一下设计方的设计,综合框架因素,觉得这种水平的设计太厉害了,我也是做编码的,我是在很偶然的机会发现他们EJB的集群配置文件,这些文件在开发过程中不会用到,或者根本不会给你看的,呵呵。
哪个项目大的分3层,JSP -〉Servlet -> EJB
在EJB有分了很多层
Service层,所有界面都对应几个Service,每个Servcie是一个Stateless Session Bean,
Service层,调用的是Contrallor层,每个Controllor对应一个业务,这一层实现业务逻辑,每个Contrallor也是也Stateless Session Bean。Contrallor层调用Module层,Module层实现数据可靠性维护,Module层还是Stateless Session Bean。Module层调用Entity Bean,这里才是真正的数据。没有作完哪个项目前,觉得好迷糊,干吗这样臃肿,笨重,我们的机子都受不了这些EJB的发布。后来好好想想,这样在维护扩展上确实最容易做到,至于速度吗,就有赖于他们机器性能,和集群的配置了。
但是具体到EJB的应用还是要控制一下EJB数量的,session bean还好了,关键是entity bean,如果是太多的entity bean性能上就有些问题了,而且集群也不太好配。
作为ejb最好以一种轻量级的个体出现
业务事物的处理最好以sessionFacade 中去体现,为了让体系更加清晰分层还可以做到:Business delegate
楼主,你们的设计还是可取的。建议你多象你们的设计人员学习
干嘛老是批评,楼主的意思也是向大家征求最好的解决方法不是嘛!~
我觉得alienbat(亡灵法师) 说话太过嚣张,如果你有真本事,你就提点宝贵的意见出来,不要在那说白话好不?