java - Making Distinctions Between Different Kinds of JSF Managed-Beans -
i read article neil griffin making distinctions between different kinds of jsf managed-beans , got me thinking distinction between different beans in own application. summarise gist:
model managed-bean: type of managed-bean participates in "model" concern of mvc design pattern. when see word "model" -- think data. jsf model-bean should pojo follows javabean design pattern getters/setters encapsulating properties.
backing managed-bean: type of managed-bean participates in "view" concern of mvc design pattern. purpose of backing-bean support ui logic, , has 1::1 relationship jsf view, or jsf form in facelet composition. although typically has javabean-style properties associated getters/setters, these properties of view -- not of underlying application data model. jsf backing-beans may have jsf actionlistener , valuechangelistener methods.
controller managed-bean: type of managed-bean participates in "controller" concern of mvc design pattern. purpose of controller bean execute kind of business logic , return navigation outcome jsf navigation-handler. jsf controller-beans typically have jsf action methods (and not actionlistener methods).
support managed-bean: type of bean "supports" 1 or more views in "view" concern of mvc design pattern. typical use case supplying arraylist jsf h:selectonemenu drop-down lists appear in more 1 jsf view. if data in dropdown lists particular user, bean kept in session scope.
utility managed-bean: type of bean provides type of "utility" function 1 or more jsf views. example of might fileupload bean can reused in multiple web applications.
this made sense me , past few hours have been refactoring code , came following respect user login:
the authenticationcontroller example of controller managed-bean. request-scoped , features 2 getters , setters setting username , password, , 2 navigation methods, authenticate , logout, navigating user either private area upon successful login, or main page when logging out.
the userbean example of support managed-bean. session-scoped , features instance of user class (which null when not authenticated) getter , setter, nothing more.
the authenticationcontroller has user managed property (@managedproperty(value = "#{usercontroller.user} private user user;). upon successful authentication, authenticationcontroller set managed property actual user instance corresponding username used login.
any new beans able grab user managed property , pull data need, such group membership instance, if user class feature list group names.
would way proper way go regard seperation of concerns?
this subjective question. disagree article , find it's giving bad advice starters.
model managed-bean: type of managed-bean participates in "model" concern of mvc design pattern. when see word "model" -- think data. jsf model-bean should pojo follows javabean design pattern getters/setters encapsulating properties.
i absolutely not make or call managed bean. make property of @managedbean. example dto or jpa @entity.
backing managed-bean: type of managed-bean participates in "view" concern of mvc design pattern. purpose of backing-bean support ui logic, , has 1::1 relationship jsf view, or jsf form in facelet composition. although typically has javabean-style properties associated getters/setters, these properties of view -- not of underlying application data model. jsf backing-beans may have jsf actionlistener , valuechangelistener methods.
this way keep duplicating , mapping properties of entity in managed bean. makes no sense me. said, make entity property of managed bean , let input fields refer directly #{authenticator.user.name} instead of #{authenticator.username}.
controller managed-bean: type of managed-bean participates in "controller" concern of mvc design pattern. purpose of controller bean execute kind of business logic , return navigation outcome jsf navigation-handler. jsf controller-beans typically have jsf action methods (and not actionlistener methods).
this describes @requestscoped/@viewscoped @managedbean class pretty much. whether event listener methods allowed or not depends on whether specific view tied bean and/or job dependent on bean's state. if are, belongs in bean. if not, should standalone implementation of faceslistener interface, not managed bean.
support managed-bean: type of bean "supports" 1 or more views in "view" concern of mvc design pattern. typical use case supplying arraylist jsf h:selectonemenu drop-down lists appear in more 1 jsf view. if data in dropdown lists particular user, bean kept in session scope.
fine. application wide data dropdown lists use @applicationscoped bean , session wide data logged-in user , preferences use @sessionscoped one.
utility managed-bean: type of bean provides type of "utility" function 1 or more jsf views. example of might fileupload bean can reused in multiple web applications.
this makes not sense me. backing beans tied single views. sounds actionlistener implementation used <f:actionlistener> in command components choice. not managed bean.
for kickoff examples of right approach, see also:
Comments
Post a Comment