java ee - JSF Controller, Service and DAO -
i'm trying used how jsf works regards accessing data (coming spring background)
i'm creating simple example maintains list of users, have like
<h:datatable value="#{userlistcontroller.userlist}" var="u"> <h:column>#{u.userid}</h:column> <h:column>#{u.username}</h:column> </h:datatable> then "controller" has like
@named(value = "userlistcontroller") @sessionscoped public class userlistcontroller { @ejb private userlistservice userlistservice; private list<user> userlist; public list<user> getuserlist() { userlist = userlistservice.getusers(); return userlist; } } and "service" (although seems more dao) has
public class userlistservice { @persistencecontext private entitymanager em; public list<user> getusers() { query query = em.createquery("select u user u"); return query.getresultlist(); } } is correct way of doing things? terminology right? "service" feels more dao? , controller feels it's doing of job of service.
is correct way of doing things?
apart performing business logic inefficient way in managed bean getter method, , using broad managed bean scope, looks okay. if move service call getter method @postconstruct method , use either @requestscoped or @viewscoped instead of @sessionscoped, better.
see also:
is terminology right?
it's okay. long you're consistent , code readable in sensible way. way of naming classes , variables awkward (illogical and/or duplication). instance, use users instead of userlist, , use var="user" instead of var="u", , use id , name instead of userid , username. also, "userlistservice" sounds can deal lists of users instead of users in general. i'd rather use "userservice" can use creating, updating , deleting users.
see also:
the "service" feels more dao?
it isn't dao. basically, jpa real dao here. previously, when jpa didn't exist, homegrew dao interfaces service methods can keep using them when underlying implementation ("plain old" jdbc, or "good old" hibernate, etc) changes. real task of service method transparently managing transactions. isn't responsibility of dao.
see also:
- i found jpa, or alike, don't encourage dao pattern
- dao , jdbc relation?
- when necessary or convenient use spring or ejb3 or of them together?
and controller feels it's doing of job of service.
i can imagine in relatively simple setup. however, controller in fact part of frontend not backend. service part of backend should designed in such way it's reusable across different frontends, such jsf, jax-rs, "plain" jsp+servlet, swing, etc. moreover, frontend-specific controller (also called "backing bean" or "presenter") allows deal in frontend-specific way success and/or exceptional outcomes, such in jsf's case displaying faces message in case of exception thrown service.
see also:
all in all, correct approach below:
<h:datatable value="#{userbacking.users}" var="user"> <h:column>#{user.id}</h:column> <h:column>#{user.name}</h:column> </h:datatable> @named @requestscoped // use @viewscoped once bring in ajax (e.g. crud) public class userbacking { private list<user> users; @ejb private userservice userservice; @postconstruct public void init() { users = userservice.listall(); } public list<user> getusers() { return users; } } @stateless public class userservice { @persistencecontext private entitymanager em; public list<user> listall() { return em.createquery("select u user u", user.class).getresultlist(); } } you can find here real world kickoff project here utilizing canonical java ee / jsf / cdi / ejb / jpa practices: java ee kickoff app.
Comments
Post a Comment