在不同种类的JSF管理豆之间做出区分 [英] Making Distinctions Between Different Kinds of JSF Managed-Beans
问题描述
我最近阅读了Neil Griffin的这篇文章在不同种类的JSF管理豆之间做出区分和它让我想到了我自己的应用程序中不同bean之间的区别。要快速总结要点：
I recently read this article from Neil Griffin Making Distinctions Between Different Kinds of JSF Managed-Beans and it got me thinking about the distinction between different beans in my own application. To quickly summarise the gist:
Model Managed-Bean：这种类型的托管bean参与在MVC设计模式的
模型关注中。当你看到单词
model时 - 想想DATA。 JSF模型bean应该是一个POJO，它遵循
的JavaBean设计模式，其中getter / setter封装
属性。
Model Managed-Bean: This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties.
支持管理-Bean：这种类型的托管bean参与了MVC设计模式的
View关注。
支持bean的目的是支持UI逻辑，并且与
（JSF视图）或Facelet组合中的JSF表单具有1 :: 1的关系。虽然
通常具有带有关联
getter / setter的JavaBean样式属性，但这些属性是View的属性 - 而不是
底层应用程序数据模型。 JSF支持bean也可能有JSF
actionListener和valueChangeListener方法。
Backing Managed-Bean: This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
Controller Managed-Bean：这种类型的托管bean参与
MVC设计模式的控制器问题。
控制器bean的目的是执行某种业务逻辑并将
导航结果返回给JSF导航处理程序。 JSF控制器bean
通常具有JSF操作方法（而不是actionListener方法）。
Controller Managed-Bean: This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
支持Managed-Bean：这种类型的bean支持 MVC设计模式的视图关注中的一个或多个视图
。典型的用例
正在向JSF提供一个ArrayList：selectOneMenu下拉列表
列表出现在多个JSF视图中。如果
下拉列表中的数据特定于用户，则bean将在会话范围内保留
。
Support Managed-Bean: This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope.
实用程序Managed-Bean：这种类型的bean为一个或多个JSF视图提供了某种类型的
实用程序函数。这个
的一个很好的例子可能是FileUpload bean，它可以在多个web
应用程序中重用。
Utility Managed-Bean: This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.
这对我来说很有意义，过去几个小时我一直在重构我的代码，并提出了以下用户登录信息：
This made sense to me and for the past few hours I have been refactoring my code and came up with the following with respect to the user login:
AuthenticationController 是Controller Managed-Bean的一个示例。它是请求范围的，具有两个用于设置用户名和密码的getter和setter，以及两种导航方法， authenticate 和 logout ，成功登录时将用户导航到他们的私人区域，或者在退出时返回主页面。
The AuthenticationController is an example of a Controller Managed-Bean. It is request-scoped and features two getters and setters for setting a username and password, and two navigation methods, authenticate and logout, navigating the user to either their private area upon successful login, or back to the main page when logging out.
UserBean 是支持托管Bean的示例。它是会话范围的，并且具有 User 类的实例（当您未经过身份验证时，它将为null），具有getter和setter，仅此而已。
The UserBean is an example of a Support Managed-Bean. It is session-scoped and features an instance of User class (which would be null when you are not authenticated) with a getter and setter, nothing more.
AuthenticationController 将此用户作为托管属性（ @ManagedProperty（value =＃{userController.user私有用户用户; ）。成功验证后， AuthenticationController 会将托管属性设置为实际用户实例，并使用相应的用户名登录。
The AuthenticationController has this user as a managed property (@ManagedProperty(value = "#{userController.user} private User user;). Upon successful authentication, the AuthenticationController would set the managed property to the actual user instance with the corresponding username that was used for the login.
任何新的bean都可以将用户作为托管属性获取并提取他们需要的数据，例如组成员资格，如果用户类将包含一个包含组名的列表。
Any new beans would be able to grab the user as a managed property as well and pull the data they need, such as group membership for instance, if the User class would feature a list with group names.
这种方式是否适合关于关注的分离？
Would this way be the proper way to go about with regard to the seperation of concerns?
推荐答案
这是一个非常主观的问题。我个人不同意那篇文章并且发现它给初学者提供了非常糟糕的建议。
This is a very subjective question. I personally disagree that article and find that it's giving really bad advice to starters.
模型管理 - Bean：这种类型的托管bean参与MVC设计模式的模型关注。当你看到模型这个词时 - 想想数据。 JSF模型bean应该是遵循JavaBean设计模式的POJO，其中getter / setter封装属性。
I绝对不会制作或称之为托管bean。只需将其设为 @ManagedBean 的属性即可。例如，DTO或JPA @Entity 。
I would absolutely not make or call it a managed bean. Just make it a property of a @ManagedBean. For example a DTO or JPA @Entity.
支持托管Bean：这种类型的托管bean参与MVC设计模式的视图关注。 backing-bean的目的是支持UI逻辑，并且与Facef组合中的JSF视图或JSF表单具有1 :: 1的关系。虽然它通常具有带有关联getter / setter的JavaBean样式属性，但它们是View的属性 - 而不是底层应用程序数据模型的属性。 JSF支持bean也可能有JSF actionListener和valueChangeListener方法。
这样你就可以保持复制和映射属性托管bean中的实体。这对我没有意义。如上所述，只需将实体作为托管bean的属性，并让输入字段直接引用它，如＃{authenticator.user.name} 而不是＃{authenticator.username} 。
This way you keep duplicating and mapping the properties of the entity in the managed bean. This makes no sense to me. As said, just make the entity a property of the managed bean and let the input fields refer it directly like #{authenticator.user.name} instead of #{authenticator.username}.
Controller Managed-Bean：这种类型的托管bean参与MVC设计模式的Controller关注。控制器bean的目的是执行某种业务逻辑并将导航结果返回给JSF导航处理程序。 JSF控制器bean通常具有JSF操作方法（而不是actionListener方法）。
这描述了 @RequestScoped / @ViewScoped @ManagedBean 类非常多。是否允许事件侦听器方法取决于它们是否特定于与bean绑定的视图和/或它们的作业是否依赖于bean的状态。如果是，那么它们属于豆。如果没有，那么它们应该是任何 <的独立实现。 code> FacesListener 界面，但绝对不是托管bean。
This describes the @RequestScoped/@ViewScoped @ManagedBean class pretty much. Whether event listener methods are allowed or not depends on whether they are specific to the view which is tied to the bean and/or are for their job dependent on the bean's state. If they are, then they belongs in the bean. If not, then they should be a standalone implementation of any FacesListener interface, but definitely not a managed bean.
支持Managed-Bean：这种类型的bean支持MVC设计模式的View关注中的一个或多个视图。典型的用例是向JSF h：selectOneMenu下拉列表提供一个ArrayList，该列表出现在多个JSF视图中。如果下拉列表中的数据特定于用户，则bean将保留在会话范围内。
精细。对于像下拉列表这样的应用程序范围的数据，只需使用 @ApplicationScoped bean，对于登录用户及其首选项等会话范围数据，只需使用 @SessionScoped 一个。
Fine. For application wide data like dropdown lists just use an @ApplicationScoped bean and for session wide data like logged-in user and its preferences just use a @SessionScoped one.
实用程序托管Bean：这种类型的bean为一个或多个JSF视图提供了某种类型的实用程序功能。一个很好的例子可能是FileUpload bean，可以在多个Web应用程序中重用。
这不是真的对我有意义。支持bean通常与单个视图绑定。这听起来太像 ActionListener 在您选择的命令组件中由< f：actionListener> 使用的实现。绝对不是托管bean。
This makes not really sense to me. Backing beans are usually tied to single views. This sounds too much like an ActionListener implementation which is to be used by <f:actionListener> in command components to your choice. Definitely not a managed bean.
有关正确方法的启动示例，请参阅：
For kickoff examples of the right approach, see also:
- Hello World example in Our JSF wiki page
- "Bookstore CRUD" example in this answer
- "Master-detail" example in this answer
- JSF Service Layer
- Communication in JSF 2
这篇关于在不同种类的JSF管理豆之间做出区分的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
