使用什么，托管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，该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.
请注意，支持bean可以直接返回实体，因此仍然可以使用bean验证.很久以前就出现的奇怪的分散/聚集"模式完全没有必要(请参见
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(..., ...);
}
}
假设在带@Entity的bean中使用SomeEntity，现在可以在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屋！
