问大家一个EJB设计的问题，有经验的进！！

Question

不需要一个界面对应一个ejb的。将一些有共同属性的抽出来做一个ejb可能会好点

Answer 1

非常糟糕，一个页面对应一个EJB？？？
EJB可是重量级的

Answer 2

to: lostfind(blueleaf) 
呵呵，我想问问，如果象你说的那要怎样来实现，不觉得这样更容易挤对？
这样对前面的servlet更加添加负担
个人意见

Answer 3

同意yeshucheng(叶澍成)的，这么大的项目，这么做有它的目的的，项目真正的运行的环境和你开发的环境是决然不同的，这样做的好处是，每一个EJB不是很大，功能分的比较清楚，到真正运行的时候，用几台服务器配成集群，到真跑的时候就知道这么做的好处了。当然有共同的方法肯定要最大限度的抽出来的。
我以前做的那个项目性质和你的一样。仔细考虑了一下设计方的设计，综合框架因素，觉得这种水平的设计太厉害了，我也是做编码的，我是在很偶然的机会发现他们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的发布。后来好好想想，这样在维护扩展上确实最容易做到，至于速度吗，就有赖于他们机器性能，和集群的配置了。

Answer 4

这的确是一个不错的方法，好像称作Policy Pattern吧。
但是具体到EJB的应用还是要控制一下EJB数量的，session bean还好了，关键是entity bean，如果是太多的entity bean性能上就有些问题了，而且集群也不太好配。

Answer 5

在某些程度上来说，不要还根据书上讲的：第三范式，呵呵。这样不太实际
作为ejb最好以一种轻量级的个体出现
业务事物的处理最好以sessionFacade 中去体现，为了让体系更加清晰分层还可以做到：Business delegate
楼主，你们的设计还是可取的。建议你多象你们的设计人员学习

Answer 6

设计极差。一个页面对应一个EJB？一杆子从显示层捅到商业逻辑层，烂到家了。去请个设计师吧。

Answer 7

想听听 alienbat(亡灵法师) 有什么好的建议，呵呵

Answer 8

TO  alienbat(亡灵法师) 呵呵，没有搂主没有说，一杆子从显示层就到了商业逻辑层呀，这么大的项目，直接从页面到EJB，再笨也不会这么吧。估计是按照我说的那种做的，但是，一个页面还是对应一个Control层，这样的看起来也是一个页面对应一个EJB，其实中间有很多层的。

Answer 9

第一次听说这样的设计，呵呵，恕我孤陋寡闻！EJB怎么又成了轻量级组件了？明明是超重量级的，你看看几千个ejb在weblogic/websphere中不死才怪。ejb重要的特性之一就是容器提供缓冲池（bean池），几千种bean每种缓冲几个到几十个你算算一共要多少？为什么要有Session Facade模式？就是因为业务bean过多，必须简化客户端的访问，不然你准备好上千个initContext, lookup, narrow，累死你。按照我的理解：这种设计绝对是最最最差劲的，一个页面对应一个bean，显示层和业务层不但是高度耦合，而且业务层逻辑混乱，可维护性最差，这种从显示层建模的方法绝对是最差的。

Answer 10

很同意楼上的说法。业务层的组件(例如，单个Entity bean)和显示层的组件(例如单个JSP页面)有什么“一对一的关系”绝对是非常荒诞的事情。试想如果要求换掉显示层或者要求使用别的技术实现业务层怎么办？你一对一的话，两层间强耦合，要改就只能一块改。另外要讲清楚如何做到层间的隔离那就复杂了，这里绝对讲不清楚。所以我的建议是：去请个架构师吧！

Answer 11

不要光说些批评的话,如果有真本事的话就说些做法出来!~
干嘛老是批评,楼主的意思也是向大家征求最好的解决方法不是嘛!~
我觉得alienbat(亡灵法师) 说话太过嚣张,如果你有真本事,你就提点宝贵的意见出来,不要在那说白话好不?