There is no degradation in performance when using business objects
(used correctly),
in-fact there is an improvement in performance in my experience!
Um.... well, that's an interesting comment. :-) At some levels I agree
with it, especially when you have a core business object (like we do)
that handles all IO because you're optimize the IO paths more than you
would if you were writing the io in each object. But at the same time,
the problem w/business objects is one that Joe pointed out, they're a
lot more "chatty" with the database then classic procedural IO would be.
You can cache object references to increase performance, but then you
have a question of currency, the cached version may not be the database
version, and this is something one has to account for in the design.
Plus, depending on your business object model, you're going to request a
lot more bytes than you would have if you were going directly to the
database. For example, say I wanted to show a list of customers in NY on
the screen. In "raw" sql I might do something like:
Select customerid, name from customers where state='NY'
But in business object land I might do:
Customer example = Customer.NewCustomer();
example.State = "NY";
List<Customer> nyCustomers = Customer.GetByExample(example);
In the first case I'm only moving the customer# and name over the wire
from the database, but in the second case I'm moving the entire customer
row over the wire. Of course there are optimizations like telling the
GetByExample() function that columns to get.
What we've found is that there is a theoretical performance _hit_ in
using business objects over highly-optimized hand-coded io, but in
practice it's roughly a push because the hit is small and one rarely
writes highly-optimized io code. :) By small we're talking hundreds of
microseconds to a couple of milliseconds in most cases. That's a
tradeoff I'll take any day of the week for the programmer productivity I
gain.
Oh, and we do special case certain objects that have _very_ large row
sizes. Like rows that store attachments with BLOB fields where the row
length is measured in megabytes. :) In those cases the BLOB data is not
retrieved w/the row but only when it's actually asked for. Of course
that's completely transparent to the consumer of the business object who
simply does:
Attachment a = Attachment.GetAttachment(12345)
AttachmentFile af = a.GetCurrentAttachmentFile();
Print("Attachment {0} has a mimetype of {1} and has {2} bytes",
a.DisplayName, af.MimeType, af.GetFileBytes().Length);
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
midrange.com
