EJB3+spring2.5+struts2和ejb3+servlet增，删，改，查实现！

冗余设计了，的确
spring跟ejb本来就不是用来结合开发的

是的，这个东东前段时间已经用过！

至于整合是多此一举，我也不这么认为，认为尽管ejb3是规范，而Spring是框架，但是成功整合他们可以创建出功能比较强大的应用程序，也就是说你可以在spring应用程序中使用部分或者全部EJB3实现，这样Spring就可以简化EJB3和jPA的使用！也就是说Spring bean可以访问ejb3会话bean并且重用业务逻辑！当然这个小小的案例没有体现出来！仅仅是作为入门的学习而已

还有阁下的意思还是ejb和spring是替代关系，我不这么认为，认为他们各自有优缺点！
1：依赖注入的比较：Spring支持一般意义上且复杂的DI API，其基于XML配置文件。EJB3.0支持大多数普通服务对象（如EJB及context对象）的注入和任何简单注解的JDNI，虽然，Spring里基于XML的依赖注入语法复杂，但却功能强大。
3：声明性事务比较：EJB3.0运用Java注解来配置声明性服务，而Sring使用XML配置文件。在大多数情况下，EJB3.0注解方式对于这种服务更简单明了！
等等  可以知道他们都是各有优点，不能简单的理解为替代的关系！当然小弟也是刚入门，有什么不对的，请指示！

楼主用的技术很复杂，EJB+spring很少有人用这个组合

可以看看Rod的那两本书，spring并不能完全替代EJB，只是对于非分布式的，可以替代，当然spring+web service也可以实现

好的，有时间看看这两本书！谢谢！

看看Spring手册第18章的概念 明显是互补和增强，而且Spring的作者也不再Without EJB了。
为了避免底层代码的重复，许多EJB应用程序采用了Service Locator和Business Delegate设计模式，这比在客户端程序中使用很多JNDI查询要好很多，但其缺陷也是十分明显的，例如：
*  依赖Service Locator和Business Delegate singleton的程序代码通常是难以测试的。
*  若只使用Service Locator模式，而不使用Business Delegate，那么应用程序依旧必须调用一个EJB Home的craete()方法，并处理各种异常。因此，应用程序将与EJB的API与复杂编程模型紧密耦合在一起。
*  使用Business Delegate模式通常将造成大量的重复代码，仅仅为了调用EJB的同一个方法，开发人员必须编写许多程序。

而通过Spring，则可以创建和使用在Spring内部配置好的代理，这个代理将扮演业务delegate的角色，开发人员无需编写另外一个Service Locator和JNDI查询代码，也无需复制Business Delegate的方法调用，除非是在这些程序代码确实有其他有价值的内容。

用spring干什么，直接用struts+ejb就可以了。

spring用的越来越过了

都用ejb3了，直接用Seam框架多好

struts做为control, ejb3作为application, spring做service, 持久ejb3 entity可以满足了,

哈哈