Peter,
So I'm guessing you have something like:
userQuery = UserService.getAllUsers("firstName, lastName, age, fullName,
homeLatitude, homeLongitude")
Pretty much:
qUsers =
Application.Users.getUsers(hasEmailAddress=true,fieldlist="firstName,
lastName, age, fullName, homeLatitude, homeLongitude")>
(for example)
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.
That would work. I actually have empty fields in my query for the
calculated fields and then if any of them exist, I loop over the query
(once) in the method and do something like this for each row.
<cfset
QuerySetCell(qUsers,"fullName",makeFullName(firstName,lastName),CurrentRow)>
I may have to ensure that firstName and lastName are in the original
query if the fullname column is requested, but that is trivial. This
makes the makeFullName internal method a bit easier to unit test.
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).
I think this is a separate issue from encapsulation. I do see some
benefit in doing things the popular way, but not enough to be
determinative. Certainly, if I were using another language then that
would affect my decision heuristic. In JavaScript, for example, I do use
Objects. That is natural to how JavaScript works.
Within the ColdFusion universe, I don't particularly think OO is
dominant - despite the appearance among those of us on lists like this
or reading and writing ColdFusion blogs. Again, not that I find that
determinative.
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.
Only if I don't also make myself cognizant of other "more popular"
approaches. ColdFusion's bad object creation penalty is non-trivial here
as well. Queries are stinking fast by comparison.
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.
This is a whole other topic. I'll try to write a blog entry on it
sometime. For now, we'll have to agree to disagree. Still, separate from
the encapsulation argument.
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.
Well, I'm not doing OO or Rails. If I were using Rails, I would be doing
OO and I would not have that rule.
Thanks,
Steve
--
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.
