On Apr 26, 2005, at 5:54 PM, Andrew Scott wrote:
So if I have a simple class called Hotel. Which can be extended by Floor,
as well as Elevator. This I understand and comprehend, but the business
logic of storing/retrieving the data (DAO) is getting me a little confused.
I'm not sure this is proper OOP. Neither Floor nor Elevator are a Hotel. Perhaps a Hotel is composed of Floor objects...
So with that in mind, what and how do you guys lay out your business logic,
dao etc. I have a complex Intranet system that could benefit from this
method, but can't use MACH-II as the framework will not be supported by
MACH-II, please don't get me to explain this I have tried to get it to work
with MACH-II just that we are doing things that MACH-II will not cope with.
I bet there is people on this list that can help with that too!
So with breaking the logic, and views down to a smaller and manageable package I would like to break down the code we currently have and start creating a more package orientated approach. But would like to see how others are approaching this as well.
I first created my namespace, edu.ucsb.graddiv. I then grouped related objects together in packages, then subpackages, and so on. For example, within the graddiv package is a student and an employee package. Within the student package are separate packages for prospective students and enrolled students.
This goes on forever...if you've done it with Java, then it applies here, though you may want to have the list provide input on how you are extending objects and so on.
Within each "leaf" package, like edu.ucsb.graddiv.student.prospectiveStudent, are a set of classes that break up functionality, including a Business Object, Data Access Object, Gateway, and occasionally Facades, Services, and Transfer Objects. Each of these patterns are described elsewhere in great detail.
To read an object, I call read() on the DAO, which returns the BO. I update the BO, then call update(BO) to save the object. Gateways usually return recordsets, rather than objects. DAOs usually operate on one BO at a time.
HTH,
Chris
--
*************************************** Chris Dempsey Director, Information Services UCSB Graduate Division Quidquid latine dictum sit, altum videtur.
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
