I agree. Code looks a lot cleaner this way. It also means that if
you want to go to CMP later on you don't have to re-write all your
client code to use the strongly typed versions.
Tom
[EMAIL PROTECTED] writes:
> On Oct 6, Jay Walters quoth:
>
> > I have a stylistic question about EJB design.
>
> Ooh, good. Nothing get's people fighting like style debates.
>
> > Beyond findByPrimaryKey, is it better to have a single finder which
> > takes as an argument some type of query object, or a bunch of strongly
> > typed finders?
>
> I'd say that if your query can be expressed as a strongly typed finder it
> ought to be. That makes for more readable code and allows your compiler
> to aid you in the development process more. As with all style issues,
> there are always exceptions. You need to weight the benefit of the
> following different types of code. (I apologise profusely for the example,
> it's all I could quickly think of that would cause this type of
> situation.)
>
> #1-
> Collection c = home.findItemsThatFitCustomer(currentCustomer);
>
> versus:
>
> #2-
> Collection c = home.findItemsSized(currentCustomer.hatSize,
> curentCustomer.pantSize, currentCustomer.inseam,
> currentCustomer.armLength, currentCustomer.shoeSize);
>
> versus:
>
> #3-
> SizeQuery query = new SizeQuery();
> query.setHatSize(currentCustomer.hatSize);
> query.setPantSize(currentCustomer.pantSize);
> query.setInseam(currentCustomer.inseam);
> query.setArmLength(currentCustomer.armLength);
> query.setShoeSize(currentCustomer.shoeSize);
> Collection c = home.findItems(query);
>
> For me *personally* I like the second one which is the strongly typed
> version. That makes it clear that the finder only interacts with those
> specific types of values and nothing more. It also prevents the 'missing
> query element' problem of the third and insulates your Item bean from the
> details of the Customer bean (which it doesn't need to know anything
> about).
>
> The downside is the explosion of different findXXX() methods but frankly,
> once they are written, you only need to make sure they work in one place
> as opposed to every time you call it as in #3 or the need to keep your
> Customer and your Item bean code insynch as in #1.
>
> Yes, it's a lot more work up front and it's harder(?) to add new queries,
> but, like unit testing, it's real benefits come when instead of debugging
> all weekend you are at a mate's house with your feet up confident that
> your query finds exactly what you're looking for and nothing you're not.
>
> C=)
>
> --------------------------------------------------------------------------
> The fact that no one understands you doesn't mean you're an artist.
> --------------------------------------------------------------------------
> Caskey <caskey*technocage.com> /// TechnoCage Inc.
> --------------------------------------------------------------------------
> Oh no! Space monkeys are attacking! -- eddie izzard
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
