On Jan 7, 2011, at 4:46 PM, Steve Bryant wrote:
> Peter,
> Indeed! I'm excellent. Hope you are well also.
A little busy, but doing very well!
> 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.
So I'm guessing you have something like:
userQuery = UserService.getAllUsers("firstName, lastName, age, fullName,
homeLatitude, homeLongitude")
I guess if you have some logic which determines generically which fields are
from the db and which are calculated, you could write well encapsulated code
which would first construct a base query using SQL and then "for each
calculated field" would call:
newQuery = addAgeToQuery(currentQuery)
So then you'd call addFullNameToQuery(query) then
addHomeLatitudeToQuery(query), then addHomeLongitudeToQuery(query)
I can see how that could work. In effect you're adding your smart getters to
your service class instead of your business object and instead of them taking
no parameter and returning a value, they take a query and return a query
augmented with the calculated column.
There's no reason this wouldn't work. However, it's not how everyone else in
the world writes apps. The vast majority of people writing complex apps that
aren't using a functional style (F#, Scala, Clojure, Erlang, Haskell, etc) are
using an OO approach. With an OO approach, you put those smart getters as
instance methods on a business object.
Most other devs, most tooling, most design patterns and most other elements of
the craft of software development are using the standard OO approach, and with
the exception of performance issues that are becoming fairly unimportant, I
don't think the "put all the methods into the service class" is substantially
better than the OO approach (I'd suggest that it is marginally worse, but not
unusably so).
It seems to me that by a combination of ColdFusions historically bad object
creation penalty and the way DataMapper and your coding style has evolved,
you're in a risk of painting yourself into a local optima that is not a global
optima. I would imagine that if you tried to write an app in a more OO style it
would take you longer than to create the app the way you do now (not least due
to the fact that you have good familiarity and have built a good tool chain
around your approach). The problem is that with a substantial part of the
global programming community going in a different direction, over time the
tooling supporting the OO approach is going to supersede what you have and
you're going to be increasingly less able to compete and/or work with other
devs used to the "more popular" approach.
> For me, this has the advantages of dealing with easy queries
I don't see queries as easier. I accept they may be more familiar to some CF
devs, but I'd argue once you're familiar with them, objects are as easy to work
with as queries - and are more flexible.
> 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.
That's pretty much the opposite of how any OO app works. ALL of them are based
on calls in the view to both business objects and view helpers. If you had no
method calls in the view in Rails or Grails, you wouldn't have an application
at all.
Personally, I'd reconsider that rule.
Best Wishes,
Peter
--
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.
