0 Replies Latest reply on Apr 25, 2009 10:56 AM by gonorrhea

    to DAO or not to DAO, that is the question

    gonorrhea

      revisiting this thread I started almost 2 yrs ago on the original Seam forum:


      my link


      Quoting DAllen from SIA book:



      There's nothing stopping you from using a data access layer in a Seam application.  In fact, for large-scale projects, I might be inclined to encourage such a design.  But Seam dispels the myth that the persistence manager must be trapped inside a DAO.  Instead, Seam proposes that the persistence manager is the DAO.

      So if you're developing mostly small (say less than 10 JSF) Seam apps, are you better off not using a DAO layer and sticking with application transactions (SMPC plus manual flush)?  Especially if the DAO would be not re-used anyways if you create a separate DB instance for each project.


      There's also the problem of composite DAO (where the query for a select is based on more than one entity).  It seems to me most non-trivial queries involve joins of tables, and thus you're better off writing a EntityManager.createQuery() statement to get your result list.


      Or is it better to use the SAF (Seam Application Framework) which is not used much at all in the Seam examples (only SeamDiscs had a reference to EntityController, for example).



      The Seam Application Framework is a variation on the generic DAO framework, except it gets the persistence manager and the page controller to work as a single unit rather than introducing an additional layer of stacking.

      Can you still have atomic conversations if you do use DAOs (I'm assuming you would basically @Inject the DAO classes into your SFSB)?


      Think about the situation in which a dataTable in your JSF retrieves and displays a record from a table, say via a createQuery() call in the SFSB.  The user can modify some of the input fields in the form on the JSF.  If you started a LRC with MANUAL flush mode, then you merely flush() the SMPC in the @End method when user clicks submit.  No data access API calls are required (e.g. merge()) due to the write-behind functionality of the first level cache/SMPC!


      In the case of a single entity backing the form fields, it would be nice if Seam was smart enough to not require a persist() call in the case of a new record submission from the client's form.  Merely a flush() as before should be sufficient.




      With SAF, the persist(), update(), and remove() methods on org.jboss.seam.framework.Home take care of flushing the persistence context.

      So in practice, how many Seam projects actually use DAOs, how many use SAF, and how many do it my way (neither)??