使用什么，托管 bean(支持 bean)或实体 bean? [英] what to use, managed beans (backing beans) or entity beans?
问题描述
我看到很多例子将 bean 标记为实体 bean (@Entity) &命名 bean (CDI)，以避免创建 2 个类(托管 bean 和实体 bean)，并利用 Bean 验证，以便可以在客户端和实体上执行验证.服务器.
I see a lot of examples marking beans as entity beans (@Entity) & named beans (CDI), so as to avoid creating 2 classes (managed bean & entity bean) and also to make use of Bean Validation so that validation can be performed on both client & server.
那么我是否应该使用单个类，是否存在任何问题，或者我应该让托管 bean 或服务层使用托管 bean 中的数据创建实体 bean?
So should I be using a single class or not, are there any issues or should I be having my managed beans or service layer create entity beans using the data from managed beans ?
推荐答案
@Named 或 @ManagedBean 注解通常用于让 bean 容器 (CDI/JSF) 在被表达式语言引用时按需创建 bean 的实例在 JSF 中.
The @Named or @ManagedBean annotations are typically used to let the bean container (CDI/JSF) create an instance of a bean on demand when referenced by expression language in JSF.
对于@Entity bean，仅仅获得一个任意的新实例通常没有多大意义.@Entity 与持久身份有很强的联系.因此，这样的实体是从 Entity Manager 而不是从 bean 容器请求的.
For an @Entity bean, it often doesn't make that much sense to just get an arbitrary new instance. An @Entity is very strongly connected to a persistent identity. Such an entity is therefor requested from the Entity Manager and not from a bean container.
典型的模式是有一个(细长的)支持 bean，它被命名为调用服务(在 Java EE 中通常是 @Stateless).然后服务返回实体.
The typical pattern is to have a (slim) backing bean that's named making a call to a service (which is in turn typically @Stateless in Java EE). The service then returns entities.
在一些非常琐碎的系统中，人们有时确实将服务命名为可直接用于 EL.但是，最终您往往希望让后台代码"生成人脸消息或处理(表)选择，这些都是纯业务服务不应该关心的事情.
In some very trivial systems people sometimes do make the service named and thus directly available to EL. However, eventually you often want to let the "backing code" generate faces messages or handle (table) selections, which are all things that should not be the concern of a pure business service.
另一个常见的快捷方式是让支持 bean 直接包含业务代码(例如，检索实体的实体管理器).这使得业务代码难以重复使用，但如果应用程序是微不足道的并且不需要重复使用，您可能会侥幸逃脱.
Another common shortcut is letting the backing bean contain business code directly (e.g. the entity manager that retrieves the entities). This makes the business code hard to re-use, but if the app is trivial and there's no need for re-use you might get away with it.
但是让实体成为支持 bean 的情况很少见，并且与常见的 Java EE 模式背道而驰.
But letting the entity -be- the backing bean is rare and anti to the common Java EE patterns.
请注意，backing bean 可以直接返回实体，因此仍然可以使用 bean-validation.很久以前出现的奇怪的分散/聚集"模式没有任何必要(请参阅 这个问题).
Just note that the backing bean can return the entity directly, so bean-validation can still be used. There is no need whatsoever for the strange 'scatter/gather' pattern that crept up a long time ago (See the second example in this question).
例如
@ViewScoped
@ManagedBean
public class BackingBean {
private SomeEntity myEntity; // + getter
@EJB
private Service service;
@PostConstruct
public void init() {
myEntity = service.getSomeEntity();
}
public void save() {
service.save(myEntity);
FacesContext.getCurrentInstance().addMessage(..., ...);
}
}
假设 SomeEntity 在 @Entity 注释的 bean 中，现在可以在 Facelet 上使用 bean 验证，例如:
Assuming SomeEntity in an @Entity annotated bean, bean validation can now be used on a Facelet like:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
>
<h:body>
<h:form>
<h:inputText value="#{backingBean.myEntity.name}" />
<h:commandButton value="Save" action="#{backingBean.save}" />
</h:form>
</h:body>
</html>
如果对 SomeEntity.name 有约束，它将被验证.
If there's a constraint on SomeEntity.name it will be validated.
这篇关于使用什么，托管 bean(支持 bean)或实体 bean?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
