On Mon, May 13, 2013 at 2:59 AM, Boris Horvat <horvat.z.bo...@gmail.com>wrote:
> Hi all, > > Hi! > I have a question about what should be the best way to use hibernate > session in tapestry. > > My environment consists of 2 layers (relevant to this). > > The first one would be a group of classes that represent an access point to > a table. For example if I have a table student then I will have a class > DAOHibernateStudent. This class receives Session object in its constructor. > Doing it this way I can separate all of the queries that are available for > that table into its own class. > > Thats strange naming, I would name the interface as StudentDAO, and implementation as just StudentDAOImpl. Note that you can also @Inject session to your DAO, you don't have to pass it through the constructor. Btw, in my projects I never put @CommitAfter annotations in this layer. In this case I can do more than one DAO-method-call in a single transaction. The second layer is a class called Manager that implements business logic. > This layer has fields that represent different DAOHibernate* classes. They > are all passed down using constructor. This way I can keep my business > logic in a special class which will communicate with different table > using different DAOHibernate* objects > > Again, you don't have to pass DAO instances via constructor, use @Inject. Having one big Manager class looks like God Object anti-pattern to me -- http://en.wikipedia.org/wiki/God_object I usually have one Manager class per table, so in it would be named StudentManager in your case. Its okay having multiple different DAO instances to be injected in this ConcreteManager class also, as well as another manager classes if you wish. Usually I put most of @CommitAfter annotations on this layer, some of them goes to page classes event handlers directly. Depends on use-case. I use @Inject annotation to inject manager into a page > > Lets imagine that I want to create a new Student. So my code would call a > Manager's method createStudent(some data) which would then use a few of the > DAO classes to do all sorts of stuff (e.g. create a student, register > subjects for him, assign him a mentor, add him to a student group, send > notification email and so on...). > > The problem that I see here is that since all of those DAO classes are > independent I need to use few Session objects as each one will receive its > own session object. So here are my questions. > > As far as I know in tapestry there is only one instance of Session object per request (at least by default) -- its a per-thread proxy. And this Session instance is shared across all your DAO/Manager instances. > > 1. Will every time when someone loads/refreshes/opens the page a new > Manager class be created which will in return create a new DAOHibernate* > objects and each one will receive a new Session object? > There are only two scopes for tapestry services now: SINGLETON and PERTRHEAD http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/ScopeConstants.html So if you bind your service via AppModule then by default you declare singleton instance. So only one instance of your Manager/DAO classes will be created and injected to your page instance. Btw, there's also only once instance of your page class will be created and shared across all requests. 2. Is it a good idea to use different session objects for the same > transaction I guess (yea I know that it is not good idea so moving to > the > next question) > As I said above, you usually have one Session object per request, and its okay. Since you will use single session instance you will have common first-level cache for all your request-scoped-queries, which is also good, I think. > 3. How should this problem be solved? Should I pass new session object to manager and then pass it as a method parameter to the DAOHibernate* > Leave session management to tapestry and only think about transaction scope, i.e. where to put @CommitAfter annotations. Use @Inject to inject sessions and other tapestry services to your classes. > 4. Any general tips about this approach? > Thanks all, > > Cheers > > -- > Sincerely > *Boris Horvat* > -- Dmitry Gusev AnjLab Team http://anjlab.com
