Why DVD store lost its architecture?

[marius.oancea]

When seam team ported dvdstore to seam, the application lost the layered architecture that was a very nice one.

What is the reason for that ?

Why noone of the examples is layered?


I imagine to write a Swing client that use one of the business metods.

Why to write a session bean that has injected FacesContext and so on. Maybe some design rules has to exists to avoid such things. Or? What is your opinion?

[gavin.king]

We want to make the examples as simple as possible to understand. You can reproduce the layering if you like, using Seam.

[norman.richards]

They layering was the thing I hated most about the EJB3 DVD Store. It made no sense. I couldn't query or do things I wanted to in my backing beans so I shoved it all behind a session facade and hid behind a "design pattern". The Seam version is much better. However, I do regret not splitting it into multiple packages. There are too many different types of classes all together.

[norman.richards]

I should point out that I never had any intention to have swing client or any other front end I didn't make the session beans remote and had no desire to. Had there ever been any notion that it was anything more than a web application, it would have been an interesting architecture to consider.

As Gavin said, if that is a design goal you can still do that with Seam and it would look something like the original DVD Store. But I'm pretty much on board with the idea that a web application should be a web application. There's no need to introduce distributed components or complex architectures, unless of course there is an actual need to introduce distributed components and complex architectures. In this case, there's just no need.

[marius.oancea]

In a unlayered app i fill i loose control. Seam even helps loosing the control by allowing bijection. I do not say seam is bad but i still think we need some design rules (in a wiki or somewhere).

I think bad design is too easy with seam "Good design should be easy, bad design has to be possible ..."

[norman.richards]

I disagree. Good SIMPLE design is encouraged. In the DVD Store, the layering is unnecessary and thus is bad. You can still layer and create a bad architecture for a web application if you want. Or, you can layer and add a distributed component which would be good if that is what you want. But for a web application, the Seam architecture is wonderful.

[marius.oancea]

Ok, i'm programming engeneering teacher at university and maybe i tend to overengineer everything. Thanx very much for sharing your thoughts.

[rwallace]

I had the same question. Mostly on if you have a layered architecture with a dao layer, a service layer, and a presentation layer, is it even still possible to use Seams conversations?

It doesn't seem like it because in the Hotel Booking example the HotelBookingAction declares an extended persistence context on the entity manager. But, if the architecture were layered you couldn't do that because you'd only have access to the service layer, which uses the daos which is where the entity manager is actually used which you likely don't want to declare as being extended.

Also, what does it do to the members annotated with @DataModel? Are they still able to be used in the same way or will you have to take special care so as not to get LazyInitializationExceptions? If you have to take special care, it seems that Seam is really only meant for small applications and really geared towards enterprise apps.

Thoughts?

[norman.richards]

Seam would work fine with detached objects. (no extended persistence context) I don't understand what you think would be the problem.

[patrick_ibg]

If implemented as ejb3 session beans, the dao beans should inherit the extended persistent context declared in the SFSB service layer beans. Assuming I understood the EJB3 specs correctly.

Anyway, I'm using a layered architecture (entity beans + daos + SEAM + JSF) and conversations seem to be working fine.

[rwallace]

Seam would work fine with detached objects. (no extended persistence context) I don't understand what you think would be the problem.

Well, I'm thinking of the situation where I have an architecture where I have entity beans, persisted by daos, which are accessed by stateless service beans which are used by either JSF beans or web services. Basically, I'm concerned if the DataModel is saved in the session across requests then using something like a scrollable data table would cause a LazyInitializationException because the Hibernate session that loaded the collection would have been closed. Or, would it be automatically reattached or something?

[rwallace]

"patrick_ibg" wrote:
If implemented as ejb3 session beans, the dao beans should inherit the extended persistent context declared in the SFSB service layer beans. Assuming I understood the EJB3 specs correctly.

Anyway, I'm using a layered architecture (entity beans + daos + SEAM + JSF) and conversations seem to be working fine.

Sorry, I'm a bit new to the J2EE and EJB stuff, what do you mean by "SFSB service layer beans"? And if I understand your arch, the JSF backing beans in SEAM access the doas so that is where all your business logic is implemented, but if you wanted to add a web services API you'd need to take the business logic out and add in some stateless service beans between the daos and the JSF backing beans so that you could expose the same functionality to the web services as you do the web app without having to rewrite a bunch of code. So, in the scenario, where would the persistent context be declared?

I suppose I may be having some problems with how transactions are handled in this architecture. I mean, when you annotate the JSF backing bean to say it depends on a Dao, is that there you're declaring the persistence context? So, in my situation where I have an added business logic layer I'd declare the JSF backing beans to depend on those beans and annotate them with an extended persistence context? Would that handle it?

[patrick_ibg]

You can declare the persistence context in the DAOs *AND* in your business logic layer. The DAOs can remain stateless. If your business logic bean is stateful, and you declare your persistence context there as EXTENDED, then when you use a DAO (via SEAM injection or EJB lookup) it will inherit the EXTENDED persistence context from the calling bean.

So: use a Stateful Session Bean (SFSB) and inject it with @PersistenceContext (EXTENDED). Keep your @DataModel as a property in the stateful bean and you should be able to access it across multiple request/responses. The key here is to use a stateful bean...

BTW, I don't it's necessary to add another business logic layer between your SFSB and the DAO layer, because the SFSB *is* essentially your business logic layer. Just call the SFSB directly from Swing or use it as a JSF backing bean.

[marius.oancea]

Just call the SFSB directly from Swing ....

I do not think is a good idea. The most of the components are injected and use FacesContext .... so you cannot call them headless (e.g. from swing). That is why rwallace is thinking at another layer where the bl has to stay (IMHO).

[patrick_ibg]

I don't see why not... the injected components are for use by the SFSB, not by Swing or whatever calling client. Swing can call the @Remote interface of the action bean, and Seam should be able to intercept the method calls fine, I *THINK*. (Disclaimer: I've never tried SEAM outside of the HB3/EJB3/JSF stack.)

I suppose you could add a layer of DTOs and Assemblers, but yeesh... it's just way too much effort to save on bandwidth, considering that even web apps are going the way of AJAX these days... In any case, the action bean still acts as the business layer.