Hi Dave,
Thanks for the reply.
I do however have some questions, in fact the same questions asked of me
when I first proposed the serviceCFC and DaoCFC approach to my colleagues.
On 05/01/2012, at 6:45 AM, Dave wrote:
>
> RE: DAO's. My approach is to define the DAO's responsibility as
> "mapping single objects to DB records." The service layer / managers
> should not know/care about how the objects get persisted/un-persisted
> (queries via the CFQuery Tag). Your DAO "layer" consist classes (one
> per object, eg, fooDAO) which contains methods like read(fooID), which
> returns a object of type foo, and save(foo), which figures out if we
> are doing an insert/update & persists the object.
>
> The advantage of this approach is that when you feel comfortable with
> using ORM, you can change your entire code base to ORM simply by
> changing your DAO's & not having to change your entire service layer.
>
> IE, under ORM, you still have a fooDAO.read(fooID) but instead of
> these methods calling cfQuery tags, they change to be calls to
> entityLoad("foo", arguments.fooID), the same applies to fooDAO.save(),
> which would call entitySave(arguments.foo). Your service layer still
> calls fooDAO.read(fooID), etc
>
Regardless of what CFC your changing,
You still need to edit XX number of functions to now use entityLoad() /
entitySave() etc.
What have I "really" achieved by having the DAO separate from the service
layer, if it is merely the location of that code changed that is different?
Also, by having the service layer as well, I am now creating an awful lot
of duplicate code.
I now must have;
serviceLayerCFC.getMyObject() AND
daoCFC.getMyObject()
And that is for every CRUD operation for every object.
That is a substantial amount of code duplication ... and while copy/paste |
code generation are your friends in this regard...
It still increasing the amount of code, the amount of unit tests I need to
write / maintain and the total lines of code that I need to wade through
for debugging / troubleshooting.
It almost seems like "someone" at some point in time said;
"this is how to do OO application architecture for (insert some language
here... Java | Smalltalk | COBOL | C++ ..."
And subsequently when CF MX came out... all the "classically" trained
developers chimed in with;
"Well you need to have a separate service layer to the gateway/DAO"
And because it was said - by someone that was respected... it must be
gospel, simply because that's how they did it with Java | Smalltalk ....
It is worth noting, that CFBuilder's ORM object generator extension ONLY
creates;
object.cfc
objectService.cfc - there is no separated gateway/DAO.
Now, I am not saying that you and everyone else that proclaims that having
a separate service CFC from the gateway/DAO are wrong.
I don't profess to know the answer - and thus the entire point of this
thread...
I am just saying, "Show me a definitive, real world example, where having
the two separated has made a substantial impact on the delivery time of an
application.
Or show me an example whereby having them separated has had XXX positive
effect.
Simply saying it should be this way, because a design pattern in the Gang
of Four's book says so... or because that's the way it is done in Java /
C++ and they're OO languages, so therefore it MUST be the way to do it in
dynamically typed CFML... I just don't buy it.
I think that this ability, which is refereed to as "change an objects
> internal implementation without changing it's external interface" is
> one of the real benefits of OO programming & is probably one of the
> skills/thought processes to learn first.
>
> Think of your objects/classes as "black boxes" that operate on other
> objects. If you calling code has no knowledge of how these black
> boxes work, then it does not need to change when you decide to change
> the inner workings of the black boxes. IE, you can change code in one
> area without breaking other areas of your system.
>
But I still have to change code "somewhere", right?
What difference does it make where I change it?
I wholly agree that maintaining the "public API" of the DAO can / does
limit the amount of code changes needed to be made elsewhere.
But because I have unit tests... finding those "other" spots is relative
easy.
But as you mentioned in an earlier reply ...
Who ever really changes their DAO / persistence technology after an
application has been deployed?
So the main advantage of loosely coupling the DAO and objects, via the
service CFC, would seem to offer a limited "real world" benefit.
It is also not lost on me what Dale asked in his earlier reply.
If the DAO is not returning the data in the appropriate format, why not
just change the returnType / structure of the DAO?
In my case, this application is relatively new so any code that replies on
the query object being returned could and probably should be changed to use
objects.
Otherwise further complications might arise later with respect to data
concurrency, particularly if we implement ORM and now have some stuff being
modified directly in SQL.
Lastly, please, realise I am not trying to "shoot down" your suggestions /
methodology, I am just trying to "flesh out" how "I" am going to benefit
from the separation of the service and gateway/DAO CFCs.
Gavin.
--
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/cfaussie/-/exN-zXfER20J.
To post to this group, send email to cfaussie@googlegroups.com.
To unsubscribe from this group, send email to
cfaussie+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/cfaussie?hl=en.
