Seam project structure and Presentation Layer
joshd Jan 11, 2013 4:55 AMI'm in the process of planning to moving a Seam 2.3 project from Tomcat (Seam with POJO) to JBoss 7 to use full EJB capabilities. I chose to go for a maven-based EAR packaging, since all Seam examples do so, and I also like the idea of separated projects.
So lets say I have a project structure like:
- foo
- foo-ear
- foo-ejb
- foo-web
What I see in all of the provided Seam exmaples and maven project archtypes - none of these is using Java classes in the web-project (foo-web here). Is there a reason for that?
If someone aims at a "seperated presentation layer" wouldn' it be a good idea to put Backing Beans (JSF/RichFaces/Primefaces whatever) and UI-related Seam-action (POJO Seam components) into this project? And only have business logic EJBs, Entity and Daos etc. in the foo-ejb? Doing so would make it possible to change the presentation layer without touching anything else - just by completely replacing the whole foo-web project.
Example:
foo-web/src/main/webapp
<p:dataTable id="groupGrid" value="#{groups}" var="group"> <p:column headerText="Groups"> <h:outputText value="#{group.name}" /> </p:column> </p:dataTable>
GroupAction providing the #{groups} in
foo-web/src/main/java/ui
@Name("groupAction") @Scope(ScopeType.CONVERSATION) public class GroupAction implements Serializable { @In private GroupDao groupDao; @In private GroupService groupService; @Out(required=false, scope=ScopeType.PAGE) private List<Group> groups; @Factory(value="groups") public void getGroups() { groups = groupDao.findAll(); } }
The GroupDao is a SLSB in
foo-ejb/src/main/java/dal and
and GroupService a SLSB in
foo-ejb/src/main/java/services
@Stateless @AutoCreate @Name(GroupDao.NAME) public class GroupDaoBean extends AbstractDao<Group> implements GroupDao { ... }
@Stateless @Name("groupService") public class GroupServiceBean implements GroupService { @Logger private Log log; @EJB private OtherDao otherDao; @EJB private UserDao userDao; .. }
I have tested a bit with this structure, and it works. Is there any good reason not to have it like this? Will it have any downsides or even serios problems? I dont find examples for having Java code in the web-project.
With the idea of having presentation logic separated from the business logic in mind, I always wonder why someone would have a "weblogic"-package right next to the "datamodel"-package, both in ejb-project.
I would be very interested in some feeback. How are you structuring small-, mediumsized- or big projects.
Thanks in advance
josh