2 Replies Latest reply on Jun 2, 2007 5:30 PM by Ryan Levering

    Transparent Persistence

    Ryan Levering Newbie

      This is a funny question to ask given that the point of Seam is to tie together different layers of the web framework, however, does anyone have any architecture suggestions for creating a fairly transparent data layer using Seam?

      My problem is that I'm working with an existing data layer interface API and in trying to conform to it, the data objects don't map neatly into entity objects. They often contain relationship management as well, ie. Division has a addDepartment method, assuming a Department wasn't a first-class object. So I think I need an underlying entity layer and then create the actual interface implementations as either POJOs or session beans. I guess my point is, is there any way to keep this extra abstraction level and still get some nice things from Seam like conversation-managed persistence? What types of objects should I make the in-between layer so Seam can understand that I'm not done with the EntityManager?

        • 1. Re: Transparent Persistence
          Gavin King Master

          Sure, nothing stops you from using a DTO layer in Seam. I'm not quite sure I understand what you are asking?

          • 2. Re: Transparent Persistence
            Ryan Levering Newbie

            I think the question is confusing because I have several symptoms and I'm looking for one cause. I assumed not directly injecting the entity manager into my action listener beans was the cause of a problem. But if I'm using an extended persistence context, the persistence context should always last the length of the conversation no matter where in the code its being injected, right?

            Now I think my issue was that some of my code was using the old way of getting an entity manager and creating from a JNDI looked up EMF. I assumed that because I was not using transactions directly or even modifying data, where I got the EM didn't really matter. Seam really didn't like this or something I was doing (kept destroying stateful beans before the conversation ended) and many problems resulted with using things like @DataModel and in parameter redirection. For some reason, I was able to get around this by creating a fake long running conversation even though it wasn't really needed. However, this is coming back to bite me as I'm adding admin features and data isn't being updated in the db.

            I guess I'd like to know if my thoughts even make sense and more specifically, if there's a relationship between the EM and how Seam ends conversations.