yes, the transactions - interesting point.
because of size we've had to break up functionality into different "services"
or business objects, each with their own DAO.
while a particular "service" can natively talk to it's own DAO ("persist")
(service)
result = false
start trans
if not perisist.doesStudentExist(id)
persist.insertNewStudent(data)
result = true
end if
end trans
return result
... some of our integrity checks are across modules (services). the only way we
can do that is to take it up a level to the controller (here's a different
example)...
(controller)
result = false
start trans
if not service.donor.IsStudentADonor(id)
service.student.DeleteStudent(id)
result = true
end if
end trans
return result
or go the other extreme and deal with the tables that make up the other
services (eg: donor) as part of the current service called (eg: student) which
destroys the idea of distinct CRUDS per module
(deep within the DAO)
function deleteStudent()
result = false
start trans
if not query.donor.ADonor
query.student.deleteStudent
result = true
end if
end trans
end function
hmmm.....
Barry Beattie
CF Web Developer
Alpha Business Systems
[EMAIL PROTECTED]
�
Ph: +61 07 3216 0999
�
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robin Hilliard
Sent: Thursday, 9 December 2004 11:10 AM
To: CFAussie Mailing List
Subject: [cfaussie] Re: Erm, Architecture question...
Barry Beattie wrote:
> thanx Robin,
>
> for us this is good news - it roughly follows what we're doing. but
> say one of the CRUD methods is a delete that can only happen once
> certain referential integrity checks are done? (this db has not one
> bit of DRI in it - it all *has* to be done in code) should these
> checks be done in the DAO? or further back up the stack (as far back
> as the controller)? if this means that the DAO shouldn't have these
> "composite" methods (more than just the basic delete) then 90% of our
> deletes won't remain in the DAO... the other question (of course) is
> whether to throw an exception or just return false if the integrity
> is violated... any thoughts?
The DAO should only ever be used by the Business Logic, so get the
business logic (don't go back any further) to do the integrity checks
and then call the delete. I would dumb down the DAO and move the
integrity checks up into the business logic, because you would perform
the same checks regardless of the DAO in use.
Interesting issue this raises is whether the BL code should manage the
transaction - I think yes because the rollback conditions are all part
of the flow of the business logic. You could add the various commit,
rollback etc methods to the DAO interface so that it was up to the DAO
to perform the rollback - database DAOs would just use the cftransaction
tag, but you could imagine another implementation of the DAO that
persisted stuff as wddx packets on disk making backup copies and rolling
back if requested, using cflock etc.
Robin
http://www.rocketboots.com.au
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
