Architecture Question

[jl_monteagudo]

Hello mates,

I?ve been looking for this question in the forum, but as I?ve not found a response for it I expose my doubt here.

I?ve been working successfully till now with EJB3 and JSF, and now I want to try Seam. So, I?m reading the Seam Tutorial and there is a sentence that I can?t see quite clear : Most Seam applications use session beans as JSF action listeners.

There is the Example 1.2 below this sentence :


public String register() {

List existing = em.createQuery("select username from User where username=:username")
.setParameter("username", user.getUsername())
.getResultList();

if (existing.size()==0) {
em.persist(user);

log.info("Registered new user #{user.username}");
return "/registered.jsp";
}
else
{
FacesMessages.instance().add("User {user.username} already exists");
return null;
}
}


My doubt is that if I work in this way I tie my business tier to my view tier, so I can?t reuse my business logic in standalone applications, for example. I know that Seam was created in order to work with web applications, but anyway I think that it?d be a better practise to develop SLSB without mixing it with web code, and on the other hand, develop a JSF action listener that use the SLSB.

Don?t you think that this is a better structure or is there something that I ?m not understanding?

Thank you for your explanations.

Best regards,

Jose Luis Monteagudo

[theute]

1) You can still add layers
2) jpdl pageflows let you remove the pageflow out of the pages.

[mzeijen]

You could probably create three ejb libraries for layering.

- ejb lib for entities classes
- ejb lib for business classes
- ejb lib JSF action listeners and other web related classes

[ssilvert]

IMHO, we need to rethink why we are creating so many layers and what those layers are abstracting for us.

If you are using actions then you are using JSF, since "action" is a JSF concept. It can be argued that JSF already provides view separation through ViewHandlers and RenderKits.

The usual return type from an action is a String, which is not view-specific at all. Look closely. There is no web code in the action class. It just returns a String that indicates a state change for the client view. Isn't that a perfect way to hit the business layer? Hit the black box and then tell me if my view state needs to change.

In J2EE 1.4, you wanted to carefully make sure that you didn't pass things like HttpSession or ServletRequest objects into an EJB. With Seam/JSF, you generally don't have that problem. It's actually a bit hard to pollute your EJB with view-specific stuff like that.

Part of the beauty of Seam is that you don't have to write those ugly business proxies that translate from the web layer to the business layer. I say good riddance to that junk. It just made J2EE into a clumsy mess.

So yes, it feels like you are doing something wrong because you aren't building layers all over the place. In reality, Seam and JSF are taking care of that for you. That's exactly what frameworks ought to do.

Stan

[mzeijen]

So you are saying that I could use the same Action classes to create a non-web application with? I don't really see that. You already add a lot of annotations to the Action class to let it communicate with the view, like the @In, @Out, @DataModel, @DataModelSelection, etc...

[ssilvert]

"smies" wrote:
So you are saying that I could use the same Action classes to create a non-web application with? I don't really see that. You already add a lot of annotations to the Action class to let it communicate with the view, like the @In, @Out, @DataModel, @DataModelSelection, etc...

Yes, you can create a non-web application with those actions. I haven't seen it yet, but I'm sure that someone will come up with a pure client/server ViewHandler suitable for Swing apps. The real difference would be that rendering happens on the client instead of the server, but the response from the action would work just fine as-is.

Notice that the JSF/Seam scopes are not even tied to servlet/web technology.

None of those annotations have anything to do with a particular view technology. They are about managing state that any view is free to access.

The question is, why would you want to hide this state behind another layer? There were good reasons for it in J2EE 1.4, but with EJB3/Seam those reasons go away.

Stan

[mzeijen]

Yes, you are probably right. But creating such a view handler would probably be a lot of work and complicated to build. But I still have the feeling that an extra layer would be better. But it is a feeling and I can't really rational base it on anything.

I am playing with Seam now, so I will probably find out what it all can and can't do.

[patrick_ibg]

There's nothing wrong with creating a Manager/Service layer that's called by the JSF Action beans. That should provide you enough separation between the business logic and the view layer.

However, I think the traditional DAO layer is no longer necessary given Java 5 generics and the EJB3 EntityManager.

[mzeijen]

I also believe that DAO isn't necessary anymore. But I do believe that some helper (or service) classes are a good thing.

You would get something like this:

 view layer
 |
 |
 business layer
 | |
 | |
 services layer |
 | |
 | |
 db entity layer