相关疑难解决方法(0)

我正在阅读Java EE 6教程,我试图理解无状态和有状态会话bean之间的区别.如果无状态会话bean在方法调用之间不保持其状态,为什么我的程序按照它的方式运行？

package mybeans;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;

@LocalBean
@Stateless
public class MyBean {

    private int number = 0;

    public int getNumber() {
        return number;
    }

    public void increment() {
        this.number++;
    }
}

客户端

import java.io.IOException;
import javax.ejb.EJB;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.annotation.WebServlet;
import mybeans.MyBean;
import java.io.PrintWriter;

@WebServlet(name = "ServletClient", urlPatterns = { "/ServletClient" })
public class ServletClient extends HttpServlet {
    private static final long serialVersionUID = 1L;

    @EJB
    MyBean mybean;

    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws …

什么是EJB,为什么我们应该使用它？请用简单的语言解释.谢谢.

在我们的遗留Java EE应用程序中,有许多值对象(VO)类,它们通常只包含getter和setter,也许equals()和hashCode().这些(通常)是要在持久性存储中保存的实体.(为了记录,我们的应用程序没有EJB - 尽管未来可能会发生变化 - 我们使用Hibernate来持久保存我们的实体.)操作VO中数据的所有业务逻辑都在不同的类中(不是EJB,只是POJO) ).我的OO心态讨厌这个,因为我确实认为给定类的操作应该驻留在同一个类中.所以我强烈要求重构将逻辑转移到相关的VO中.

我刚刚与一位在Java EE方面比我更有经验的同事进行了讨论,并且他证实了愚蠢的实体至少曾经是推荐的方式.不过,他最近也阅读了有关这一立场有效性的意见.

我知道有些问题至少限制了实体类中的内容:

• 它不应该直接依赖于数据层(例如,查询代码应该进入单独的DAO)
• 如果它直接暴露于更高层或客户端(例如通过SOAP),则可能需要限制其接口

有没有更合理的理由不将逻辑移入我的实体？还是要考虑其他任何问题？

关于Java EE Web应用程序将由完整的Java EE应用程序服务器提供服务,例如GlassFish,这是最好的ORM解决方案？EJB 3或Hibernate 3 为什么？

我的问题非常简单,我的目的是生成一个包含您的响应的存储库,以便在选择用于开发企业通用应用程序的框架时可以为社区服务.这非常适用于C++,C#或Java等通用语言.

• 您建议使用什么框架来生成分层架构？
• 根据您的经验,为什么您更喜欢使用某些框架而不是您自己的架构？
• 您认为您选择的框架将作为软件开发行业首选的选择多长时间？

我是Java EE的新手,看到EJB在纯Java/Oracle社区中很活跃.然而,每当其他人甚至说出"EJB"这个词时,每个人都会在他们的脸上表现出厌恶的表情,这让我觉得他们要么已经灭绝,要么被现代开发团队用其他一些中间件技术所取代.

就像JSP已经让位于以JSF为中心的视图技术一样,EJB也是如此吗？无论哪种方式,什么是EJB的流行替代品,它们有何不同？它们提供了哪些优于EJB的优势或特性？

在使用@EJB注释时,我有一个与可能的性能问题相关的问题.想象一下以下场景

public class MyBean1 implements MyBean1Remote{
 @EJB
 private MyBean2Remote myBean2;
 @EJB
 private MyBean2Remote myBean3;
 ...
 @EJB
 private MyBean20Remote myBean20;
}  

有一个bean与其他bean有许多依赖关系.根据EJB规范,如果我想将MyBean1Remote注入其他bean,容器必须从其池中获取所有必需的依赖项,将其注入MyBean1Remote,然后注入对MyBean1Remote存根的引用.

所以在下面的场景中容器需要保留20个ejbs(myBean1及其19个依赖项)

public class MyAnotherBean implement MyAnotherRemote{
  @EJB
  private MyBean1Remote myBean1
}

假设在大多数情况下,我们将仅使用myBean1的每个业务方法的单个依赖项.因此,每次我们想要注入该bean时,我们都会强制容器保留许多不需要的EJB.让我们假设我们正在对远程bean进行操作,因此容器在注入依赖bean之前可能还需要执行一些负载平衡算法.

问题:

1. 在群集环境中运行时,这是否会导致不必要的资源预留和更多性能问题？

2. 也许好的旧ServiceLocator可能是更好的解决方案,因为有了这种方法,我们会在需要时询问特定的EJB吗？

在存储库层我定义了常规的数据操作，例如插入、查找等。@Repository我正在使用 Spring，并且在类上方有注释。@Controller例如，直接在类中使用此类是否不好？所有存储库都应该始终有一个仅委托给存储库层的服务层吗？

我已经阅读了有关有状态和无状态会话bean以及它们如何工作的各种书籍.我想知道这些ejbs的实际用法和优于使用普通java类的优点.基本上你什么时候去无国籍的ejbs,你什么时候去有状态的ejbs.我想要一个实时应用程序.

EJBS是否用于数据库支持的网站(所有人都可以访问)？

我正在编写一个网站的功能区/成就系统,我必须为我的系统中的每个功能区编写一些逻辑.例如,如果您是第一批注册到该网站的2,000人或者在论坛中发布了1,000个帖子后,您就可以获得一个功能区.这个想法非常类似于stackoverflow的徽章,真的.

因此,每个功能区显然都在数据库中,但它们还需要一些逻辑来确定用户何时获得功能区.

在我编写它的方式,Ribbon是一个简单的界面:

public interface Ribbon {
    public void setId(int id);
    public int getId();
    public String getTitle();
    public void setTitle(String title);
    public boolean isEarned(User user);
}

RibbonJpa是一个实现Ribbon接口的抽象类,避免了isEarned()方法的定义:

@Entity
@Table(name = "ribbon")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "ribbon_type")
public abstract class RibbonJpa implements Ribbon {
    @Id
    @Column(name = "id", nullable = false)
    int id;

    @Column(name = "title", nullable = false)
    private String title;

    @Override
    public int getId() {
        return id;
    }

    @Override
    public void …

我想使用java为我的应用程序开发服务层.同时,服务层也可以暴露给webservice.

我的想法是为数据库操作创建一个通用抽象类,所有其他服务类扩展该抽象类,并通过该抽象类方法执行数据库操作.

这是一个好主意吗？请帮我