"I'm stressed - please give me a moment to calm down, then try again" [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] [link] I have the book method in the client.How about you? Which one is better,client or server? I put mine on the client. That wasn't a requirement for my assignment, but I wanted to keep using the basic DB interface as much as possible to maximize reusability. Future enhancements will need read(), lock(), unlock(), update(), create(), and delete(), even though my GUI client only needs find() and book(). So the GUI uses a facade with the two methods it actually needs, but the network classes support the full "raw" DB interface.
The only reason I see to put book() on the server would be to cut down on network traffic. But (a) performance is not a bid deal here, and (b) most fo the network traffic probably comes from find() anyway - there's a
lot of data being passed that way, compared to bookings. So there's insufficient incentive to put book() on the server, IMO.
Is it redundant? Well, I'm not sure what the purpose is. As Andrew notes, you may want to return a set of unique values; it may also be nice if they're in alphabetical order. For this I'd probably use a TreeSet - just check if a value is null, and if not, put it in the TreeSet (which sorts itself for you, very nice).
[ July 16, 2003: Message edited by: Jim Yingst ]