framework OO design debugging

I got my developer app working today. This is my new app. that is utilizing pure OO techniques. It is still a shift for me, as i struggle, i see this more. Think in terms of objects, encapsulated objects, that contain their own data. Pass around a reference to this object, rather than passing along pieces of data by value. How does the object serve the application? Does the object know anything about what application is using it (lets hope not). Let the object take care of itself, keeping its own state and not reaching out to other objects (loosely coupled).

Its not ok to create just tiered applications anymore. I am thinking now more about objects and their state, relationships and bus. logic (which object should it belong, bean, service, DAO/Gateway) and even if i need a bean or service for an object. Could the entity be served by an existing object. I *should have less services than actual beans, as the application progresses. Its ok to start with the 4:1 (entity in your domain has bean, service, DAO, Gateway) - but this is a guide,not a rule! As Sean Corfield said, dont create an anti- pattern.

Anther problem i was running intois the mach-ii framework masking the errors (that i created first in my listener, then in my service, then in my DAO). The experience of stepping through the event flow is always valuable, but the framework was not helping by reporting a very unhelpful message. Is the framework really to blame for masking my mistakes? I think without a framework, i would have at least had a better path to follow regarding where CF was failing (in the listener, service, DAO/Gateway or somewhere else.

Anyway, i have worked my way through the problem. I have a listener that is handing off to a service. The service method requires a struct(listener passing in event.getArgs() ), takes the arguments passed in and calls a private method in the service that instantiates a new object and used the setter methods on that object to update with the arguments passed in from the listener. When the private method is complete creating and updating the object, it passes it back to the main method, who then calls the DAO to it its work. The resulting object reference passed back by the helper method is used as an arg to the DAO. Passing by reference, not value.

This is a big leap for me. I am not passing around a bunch of data, but rather an object reference that is resp. for keeping its own data. Object = encapsulation of its own methods AND its own data.

Im still not sure if my service is real smart, but i am passing by reference now. In my DAO create method, i will keep the validation logic around the actual SQL insert. This is keeping with the fat bus. ready object (non anemic).