On Apr 10, 2008, at 3:46 PM, Jeff Schmitz wrote:
// Question 1: Does a function like this really belong down in my EO class.
// There's something about doing the actual Fetches in this class that rubs
// me the wrong way, however I don't want to put it in my Component classes
// either since there may be multiple components that would like this
// functionality.
Does it have anything to do with the app's UI (i.e., should it be implemented in a View class)? No.
Is it "glue" between Model and View objects (i.e., should it be implemented in a Controller class like a WOComponent subclass)? No.
Could it be in any app that accesses these types of data regardless of the UI (i.e., should it be implemented in a Model class)? Yes.
Then it's Model logic that belongs in a Model class like this one.
// Question 2: If it does belong down in my EO class, does it belong in THIS EO class,
// which represents the "top of the chain"
// in a chain of relationships that are traversed to get the actual data to
// return? Or should I just fetch the entry from here first and move this function down
// into the Entry EO Class?
I often struggle with this decision (well, "struggle" is probably too strong considering genuine WO struggles :-) In this method, both Pool and Entry objects are involved. If this method returned an Entry object based on a Pool object (or Pool object name), I'd probably implement it in the Entry class. But because it's returning a boolean, I'd probably go with your "top of the chain" criterion and implement it in the Pool class. I'll be interested in reading what others would do and why.
// Question 3: Does this need to be static?
Does it work on one Pool object (i.e., is it an instance method)? No.
Then it should be static (i.e., it's a class method).
// Question 4: Is exception handling always the best way to handle the
// no results case? OR should it be saved for cases where not finding
// what you're looking for indicates there is something really wrong with
// your app?
If one and only one object should satisfy the search criteria, and 0 or more than one object satisfies the search criteria, then something is really wrong, so throwing an exception seems appropriate to me.