Sure, cases where the data being displayed has heavy business logic
associated with it is a case where a query may not work. I don't use IBOs
since I use Transfer and haven't had the time/inclination to adapt it for
use as an IBO (though a Decorator could probably be made to do this without
a lot of problems, though it may mean that you can't use the built-in
high-performance Transfer caching layer).
What I'm really trying to get across is that most people get to the idea of
OO, and the first thing they do is transform all of their queries into
arrays of objects and crush their performance. It's less of an issue now
than it was in the past, but for much of what people are doing, like
displaying news headlines, etc., a query will usually work just fine.
However, you're right, it is not a blanket statement. There are certainly
cases where it won't work or isn't the most desirable choice.
On Mon, Mar 31, 2008 at 10:57 AM, Peter Bell <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
