"So - I think I have just talked myself back into using them again...
Sheesh - I might need an afternoon lie-down.... "
Yep, learning this stuff can be an absolute mind-f**k, I'd say that
most of it comes from experience - ie, trying something on a project,
figuring out what does't feel right and looking into other design
approaches next time, etc. A lot of things that seem like overkill on
a new/small project make a lot more sense as the project gets larger.
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
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.
The funny thing is that as your learn more about OO, you will probably
take a different approach to the above problem. EG, doing object
creation in factories, which are different to your service layer,
which will then call DAO "layer" (which does not do object creation)
or a ORM "layer" - ie, the purists will think my above solution far
from perfect, and they would be right - but there is no point in
trying to learn perfect OO all in one day.
Dave
On Jan 4, 4:15 pm, Gavin Baumanis <beauecli...@gmail.com> wrote:
> It's kind of funny - but just after having writtemn the initial post I was
> doing some work that was perfect for a service ayer / manager CFC.
>
> Although very new, the DAO object was alrready in use, but was returning
> queries.
> Problem for me was; I wanted to do my new work using objects.
> (The "greater" view, to perhaps implementing ORM eventually... so working
> with objects for the new work seemed sensible.)
>
> So, I now have in my manager CFC, a method that returns an object populated
> from calling the underlying DAO "getter".
>
> I certainly could have made the change in the DAO, and had it return an
> object instead of a query...
> But... while I am not sure how common it is - I can drop back (easily) to
> the original query if needed, this way, too.
> (to perform a query of queries perhaps?)
>
> Also, in this instance, (the new work is relatively small in the number of
> object types required) - so I can certainly see the value in using the same
> manager CFC for the few objects / tables that we have deal with.
>
> So - I think I have just talked myself back into using them again...
> Sheesh - I might need an afternoon lie-down....
>
> Gavin.
--
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
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.
