On 3/31/08 10:46 AM, "Brian Kotek" <[EMAIL PROTECTED]> wrote:
> In the vast majority of cases you would not use transient data transfer
> objects to move bulk data around. If you are talking about query data, just
> return a query and loop over it to display it, the same way you always have.
> In my experience, one really only needs to deal with DTOs or Beans when
> dealing with *one* object, such as when a user is editing a news item or
> viewing a product detail page.
Oh, gotta jump on that one :->
You have a Product object. You want to display a list of products. You have
a number of different templates that display the product three different
category detail layouts which include a product list, a product search list,
two differently configured product detail screens and then there are the
products within the admin system, the shopping cart and the like. In each
case, the logic for displaying Product.Price is fairly complex and is based
on discount prices, whether the product is on sale and so on. You could
replicate your business logic in every single view, but I¹m hoping we all
agree that¹s a non-starter. You could write a script in your service layer
that transforms your recordset to add a new calculated Price field, but then
you¹re replicating the code you use in your bean when displaying the price
for a single product and you¹re sticking calculations in your service
singleton which should really be in your product bean.
Just use any reasonable implementation of something like the Iterating
Business Object. You encapsulate a recordset within a single bean so
performance isn¹t an issue and you still have well encapsulated getters and
setters that you can use for both a single bean or what acts like a
collection of beans (without the performance penalty of instantiating one
bean per instance in a list).
I¹ve been using this approach for a while now and it really works nicely.
Because the performance penalty of a single bean is so small, I never have
to worry about ³should I use a recordset or an IBO² and I have all of the
benefits of encapsulation of calculations so if my simple objects get more
complex over time (and they almost always do), I can just drop in my custom
getters (or other logic I might need) into the appropriate IBO (for the
Product or Article or User or whatever) and I don¹t have to change my views
or replicate logic in all of the views.
I¹ve tried a lot of different approaches, and I¹m willing to go out on a
limb and say this is a better solution than anything else I¹ve come across
in CF for a pretty wide range of use cases.
Best Wishes,
Peter
> Ronan,
>
> First, from your message I'm guessing that English is not your first language,
> which is fine of course. However, in the interest of clarity, try not to use a
> word like "informations" because that could mean literally anything. What,
> exactly, are you "getting" 50 times for the header, body and footer?
>
> In the vast majority of cases you would not use transient data transfer
> objects to move bulk data around. If you are talking about query data, just
> return a query and loop over it to display it, the same way you always have.
> In my experience, one really only needs to deal with DTOs or Beans when
> dealing with *one* object, such as when a user is editing a news item or
> viewing a product detail page.
>
> regards,
>
> Brian
>
> On Mon, Mar 31, 2008 at 10:03 AM, Ronan Lucio <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>>
>> A have doubt that has hitting my mind:
>>
>> Supposing I have a web page that gets about 50 informations between
>> header, body and footer.
>> Supposing such web page has about 200,000 page views per day, and 70%
>> of this access occurs in business hours.
>> 140,000 access in 8 hours = 17,500 per hour.
>> Not so much, but a considerable number.
>>
>> If I use a Data Transfer Objects, ColdFusion would get the information
>> directly from the pointer, right?
>> But it would have to execute few news CreateObject().
>>
>> If I use a Factory I could get these objects from it, but ColdFusion
>> would get the informations from the Beans,
>> but this option would cause ColdFusion execute 50 get() methods plus,
>> per page view.
>>
>> 50 get() methods may not be considerable a big number, but it can be
>> when we multiple it per 200,000 page views, especially knowing that each
>> get could have some datatype controls (get("name")).
>>
>> How do you see this situation?
>> I know this can easily solved with a cluster, but in Brazil ColdFusion
>> Enterprise insn't so accessible and maintain a big cluster some times is
>> inviable, especially with the constantly software upgrades, that should
>> be a good thing.
>>
>> BlueDragon perhaps can became a good option, soon.
>>
>> Ronan
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
