Peter,
Indeed! I'm excellent. Hope you are well also.
I have a "fieldlist" argument on my service methods. So, my
"getEmployees" method returns a query with the fields requested. It
doesn't matter that some of those fields are created by SQL and others
by post-processing. At which point I am only doing post-processing for
the pages that need it.
Internally, I can have those calculations done by other methods for unit
testing.
For me, this has the advantages of dealing with easy queries and of
being able to have a rule for "no method calls in the view" which helps
to avoid inadvertent calls to looping code from within an output loop.
I guess I still don't see how this violates encapsulation (I'm not even
sure that the issue mentioned is truly one of encapsulation). I am a
missing something?
Thanks,
Steve
On 1/7/2011 2:44 PM, Peter Bell wrote:
Hey Steve,
Long time no chat! Hope you're doing well?
OK, trivial example, I get firstName and lastName back and I want to display
fullName. If I don't have an object where I can put a getFullName() method, I
have to either iterate over the query in a service class to preprocess or
duplicate the #firstName# #lastName# code in every view which is fine until I
want to add middleInitial to everywhere I display the full name and then
becomes a PiTA in terms of maintenance.
Of course, if all we ever did was to display a fullName, this would be
overkill, but I find complexity usually grows. For example, I have a location
object in a current app. You enter an address, but you can call location.lat
and location.lng which return the lat and lng. Inside the location bean you
have:
def lat
if(!...@lat)
latlng =
GeoKit::Geocoders::GoogleGeocoder.geocode("#{self.full_address}")
self.lat = latlng.lat
self.lng = latlng.lng
end
latlng.lat
end
It's ruby code, but you get the idea. I'm populating the latlng from a Google
geocoding lookup. The alternative approach of pre-processing your query to
populate all of the lats and longs works, but the more calculated properties
you have, the more complex and difficult to maintain those pre-processing
routines become.
Such preprocessing routines also violate (to me) the single responsibility principle.
Sure, they are responsible for "preprocessing the query to generate calculated
values", but that's a big responsibility that could include concatenating fields,
pulling from third party web services and who knows what else to create the fully
populated queries with all of the calculated properties.
I just default to objects with smart getters and seldom find myself regretting
it.
Also much easier to unit test the calculations.
Best Wishes,
Peter
On Jan 7, 2011, at 3:25 PM, Steve Bryant wrote:
Peter,
Would you mind expanding on that a bit? How does the use of a query prevent
encapsulation? I realize that the data is read-only, but that doesn't mean that
the code that produced it wasn't well-encapsulated.
Or am I missing something fundamental?
Thanks,
Steve
On 1/7/2011 1:31 PM, Peter Bell wrote:
Well, I certainly wouldn't use a query object. I'm not a fan as there is no
possibility of encapsulation of any possibly business logic.
--
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en.
--
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en.
