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 - 08:56:42 EST