OO programming from domain to presentation layer

I am always trying to get a better handle on OO programming techniques. I come from that produral background and i think it is always influencing the way i see layer and communication.

If i can think of the objects as two types
singletons - only one copy exists per session per user - these have no state
(these are DOA's, Gateways, Services)

transient - have state and need to keep the state while living in memory
(these are beans or value objects)

In my main application that i support, this means

transient objects or beans that have state (specific data associated with them) are
assessments
standards (performance indicators)
resources

Each of these beans is updated when a new one is selected.

For each user a set of each is created (assesment, resourse, standard) value bean. They are created in the service that is used to communicate with them.

There is only a single service object (a singleton) that is created once when the application starts. The singleton is placed in a application scope and is then accessible to every user who comes to the site. They all share the same instance of the object or class. There is no race concerns because the application (coldFusion) takes care of the threading.

So - one instance of the services for all the users who come to the site. A collection of objects for each user when they initially hit a part of the site that uses the service for those objects.

Also in the service, besides the instantiating of the transient objects, are the rules for when to call the other singletons. The service is the big DOG. It knows about the other services and the other singleton and transient objects. If you looked into the init() of the service.

Again - think like this

- whenever you have data to persist for a value object
- ensure a copy of it exists in memory
- use the DAO to get the updated data (if reading from table)
- use the Form or URL parameters if updating to a table)
- update the current bean in memory
- pass a reference to the bean from the service into the DAO/Gateway when necessary
- pass a reference back to the presentation layer when feasible.

I dont think rules like this are always adviseable, some times it just makes sense to pass by value and not reference. But, in the spirit of OO - think like this by default and work from that position.

I did this in a couple view pages i was recently working on. The the user clicked on a resource or assessment or standard, if the request was to view something - then i would go to the service who who use the id and existing reference to the value object, and pass them both into the DAO gto get the details from the DB. If the request was a update, then i would use the updated values in the form fields and pass them along into the service and update the current bean using the arguments passed in and then pass back a reference to the value (bean) object. now in my presentation layer im referencing the bean that is in memory. Im not actually going back into the db (which is a no no from a MVC perspective) - but referencing the value bean via the object passed along. Encapsulationa and OO techniques!

Im not sure if this is really the smartest way to go about this, but it is my attemp to continue to push out OO concepts and challenge myself to learn to think in terms of Objects and encapsulation.

cheers
What i started to do recently, in the spirit of OO, is to return the pointer or reference to the presentation layer.