Re: Convenience functions in model classes
Re: Convenience functions in model classes
- Subject: Re: Convenience functions in model classes
- From: Chuck Hill <email@hidden>
- Date: Fri, 11 Apr 2008 16:48:21 -0700
On Apr 10, 2008, at 7:13 PM, Art Isbell wrote:
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.
Or in a non-EO, non-UI class. I often have "business" classes for
things like this that are not exactly an EO method but really ought
not be in the UI.
// 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.
As written, I agree. I highly recommend either (or both!) of
RebeccaWirfs-Brock's book on this area: http://en.wikipedia.org/wiki/Rebecca_Wirfs-Brock
// 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.
Aloha,
Art
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden