data update best practices 2004-04-22 - By Chuck
Back
I concur with James. Use (1), unless you have a VERY good reason to use
2,3, or 4. Since #1 is also the easiest to implement, you could start
off using it, and only move to 2,3, or 4 if you *find* that good reason
to. I tend to use Just In Time (JIT) complexity. ;-)
Please make note that the *VALUE OBJECT PATTERN HAS BEEN DEPRECATED IN
FAVOR OF THE TRANSFER OBJECT(TO) PATTERN.* There are several subtle
differences between the two.
I will also admit, though, that in many cases, I use my TO's much like a
VO, though I add more things like validation and related field
aggregation. I generally use the same TO for input/modification as I do
for output/display.
For instance, I might have following TO:
<psuedocode/>
public class AccountTO {
Long accountId;
Long bankId; // used primarily on input/modification methods such as
addAccount()
BankTO bankInfo; // used primarily on output/display methods such as
getAccount()
}
In fact, I think this is one of the TO strategies.
Also,
These are the good reasons I can think of to use the exceptions (2,3,4)
(2) This might be needed if you have a TON of concurrent users updating
the same data, though your db and other controls might be able to handle
these issues.
(3) Might be needed if your objects are HUGE and/or db access is slow.
(4) Might be needed if there are a TON of db schema changes(that you
possibly don't have control over) and db access is slow.
Charles Bradley
Senior Java Consultant
Sun Certified Java Programmer (1.1, 2.0)
>
> Date: Wed, 21 Apr 2004 19:04:29 +0930
> From: James Telfer <jt@(protected)>
> Subject: Re: data update best practices
>
> Guy,
>
> The 4 methods I know of are:
>
> 1. All
> 2. Infer
> 3. Flag
> 4. Bag
>
> (1) is the simplest, as you've mentioned, but I must question whether this
> strategy will have the impact on performance that you suggest - I'd be
> interested to hear if any of the readers of the list can shed some light on
> this with empirical data. There are some situations (such as where change
> auditing at the database level is performed) where this isn't a great idea
> from other perspectives. For simplicity, though, this is so much easier -
> unless performance is /that/ much of a concern.
>
> (2) perform equality checks to infer if a change is required. This doesn't
> work well and is definitely not performant.
>
> (3) flags, as you mentioned, along the lines of what XDoclet generates. The
> only difficulties with this approach are more complex query generation (for
> BMP) and bean update logic. If the value object is not used by a Java client
> (if, say, it is serialised via CORBA and instantiated by a different
> platform) then you will have to make sure that the client application
> correctly sets the flags - something of a pain in the neck, particularly
> where code generation is involved.
>
> (4) is one I have no experience with, but you /could/, in theory, send a map
> containing only changed values back to the server. This may not reduce
> overhead all that much, but it may have some advantages for more dynamic
> views.
>
> This may not be much help - I can only suggest that you test your solution
> to see if it really does make a difference to performance (and if you do,
> please post your results :) ). I'm hoping that others will shoot me down if
> I'm way off beam.
>
> HTH,
> JT
>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
