I couldn't agree more both on avoiding transfer objects and on relying
heavily on the frameworks you choose (ie. Cayenne). I don't know how
many times I've heard that the persistence (or whatever) should be
pluggable, so we end up hiding it's power, but how many times has a
project ever switched, and does it end up being easier, no!
J
PS. commons-persistence? I don't think so...
-----Original Message-----
From: Cris Daniluk [mailto:cris.danilu..mail.com]
Sent: Tuesday, December 06, 2005 7:57 AM
To: cayenne-use..bjectstyle.org
Subject: Re: Thread Bound DataContexts - Bad Pattern?
With Struts, you can be clever enough to always use your domain
objects to display content. Editing is a little trickier since Struts
can't populate a collection arbitrarily (i.e. create a new object).
With some more cleverness though, you can almost always use Cayenne
objects rather than having to create transfer objects all over the
place. Having recently refactored the transfer objects out of an
extremely large project, I highly recommend it. We still do have a few
select cases where we have to use transfer objects, but 95% of the
time...
I don't see any reason to shield Cayenne from your application. With
some things you want that, but for frameworks like Cayenne, Spring and
Struts, they are the fundamental determinants of your application's
architecture (aka frameworks). So, it's silly to think you could rip
out a tool like that with minimal effort just by minimizing the times
you are importing org.objectstyle.* in your code. Considering that,
why not embrace it?
On 12/6/05, Joshua Pyle <joshua.t.pyl..mail.com> wrote:
> Actually I use struts and as such I have to create "FormBeans" I've
> gotten in the habit of creating POJO mimicks of my cayenne objects and
> create a "getTransferObject" method on each of my cyenne objects.
> This "TransferObject" is a POJO that ends up making uyp my struts form
> beans.
>
> I also create a "User" object that contains methods that call my Data
> Access Objects to perform queries about the user who is currently
> logged-in.
>
> The best part of the Threadbound data context is that these user
> objects and Transfer Objects all have no knowledge of cayenne and as
> such the only layer that knows about cayenne are the Data Access
> Objects.
>
> picture this...
>
> Class UserObject(){
>
> private userName = "whatever";
>
> public boolean isAdmin(){
> return AdminDAO.getInstance().isAdmin(this.userName);
> }
>
> }
>
> and the AdminDAO uses the threadbound datacontext.
>
> --
> Joshua T. Pyle
> Go has always existed.
>
>
> On 12/5/05, Joel Trunick <joel.trunic..ebifysolutions.com> wrote:
> >
> > You mean your own DTO's or do you just unregister your Cayenne
Objects
> > so they are transient?
> >
> > I store my User object in my Visit, but by just storing it's
ObjectId.
> > My understanding is this is serializable. BTW, is there a way to
easily
> > serialize ObjectId to string format?
> >
> > J
> >
> > -----Original Message-----
> > From: Joshua Pyle [mailto:joshua.t.pyl..mail.com]
> > Sent: Monday, December 05, 2005 7:30 PM
> > To: cayenne-use..bjectstyle.org
> > Subject: Re: Thread Bound DataContexts - Bad Pattern?
> >
> > Yes I use Transfer objects to store data from cayenne over the life
of
> > a session. I've found that never storing cayenne objects in the
> > session scope cleans up my application and makes session failovers
> > much cleaner.
> >
> > Joshua T. Pyle
> >
> > On 12/5/05, Tore Halset <halse..vv.ntnu.no> wrote:
> > > On Dec 5, 2005, at 18:04, Joel Trunick 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.
> > >
> > > I am doing the same, but with DataContext bound to a tapestry
Visit
> > > object. Just include the context as a argument to the static
methods.
> > >
> > > > 1) When do you ever need multiple datacontexts? (right now from
web
> > > > app)
> > >
> > > I use extra DataContext to generate some reports as it is very
nice
> > > to be able to throw away the DataContext afterwords to save
memory.
> > >
> > > > 2) Is the thread bound context a limitation?
> > >
> > > I have not used thread bound context that much. You will have to
be
> > > sure that the contexts are the same as any data objects that live
> > > longer than a single request/response. *Or* move objects between
> > > contexts.
> > >
> > > Regards,
> > > - Tore.
> > >
> >
> >
> > --
> > Joshua T. Pyle
> > Go has always existed.
> >
> >
>
This archive was generated by hypermail 2.0.0 : Tue Dec 06 2005 - 10:28:28 EST