I'm heavily using threadbound data contexts in my web apps. Its
working great. I so need to ever have more than one datacontext. If
I need multiple mappings pointing to different databases I just set it
up in the current context. My DAO api is now clean in that the
DataContext is not passed into methods and this in effect makes my DAO
API interface unaware of cayenne.
I have found one limitation, the datacontext only lives during the
lifetime of the request and as such any chaching benefits only exist
during the processing of the request.
-- Joshua T. Pyle Go has always existed.On 12/5/05, Joel Trunick <joel.trunic..ebifysolutions.com> wrote: > > I've been putting static methods on my domain objects to perform things > like queries (for that object), and even simple methods load an instance > by ID (returning an instance of the proper type). I find this > organization very straightforward to use from a client perspective. > > However, to do this I rely on the DataContext bound to the thread a lot, > and I'm wondering if this is architecturally flawed. > > I've already recognized that some (not all) of the queries belong on the > client-side (tapestry pages), according to the DDD book, so I'm looking > at getting rid of all these thread dependent methods. > > The question is then: > 1) When do you ever need multiple datacontexts? (right now from web app) > 2) Is the thread bound context a limitation? > > J > >
This archive was generated by hypermail 2.0.0 : Mon Dec 05 2005 - 12:29:27 EST