Rather than hijack the BO(Business Object) vs. DTO(Data Transfer Object) thread I started a new one as I realize how different my code is. First it would help for me to know what to call this pattern as I get into lots of debate because it looks like DAO/DTO but its not really. So I am thinking data proxy object fits best. But I am not saying its worthy of being a pattern yet, just that if I don't name it, its just confusing...
So as you can see the classes that use my BOs really don't know about DAOs or how to 'get' the BOs as its a heirachy that starts at the top. Once you get the Project, you can get all the rest. Without the project, you can NOT get any other classes. This is by definition. Hope this does not disturb anyone.
So in some sense the BOs behave like DAO in that they return other BOs. And certainly the object that returns the Project can be called a DAO maybe. Sometimes the BO has preloaded data when it was created, like "Project" eagerly loads its "Architectures". OTOH, some are lazy loaded like "Project" lazily loads its "Citcuits".
If I changed this to standard DAO style I think it would be like this
So first I would have to create some type of IDObject which I dont have now. Then My GUI would be juggling all these DAOs AND BOs which currently it does not need to do. I think the first way is more elegant. Perhaps its because of my structured heirachy?
Have I missed anything here? [ August 14, 2006: Message edited by: Mr. C Lamont Gilbert ]
Here is example implementation of a business object.
Thats the general idea of using the proxy. As you can see, getting the initial ProjectProxy will require some type of DAO. But once you get the ProjectProxy, you never need another DAO. [ August 14, 2006: Message edited by: Mr. C Lamont Gilbert ]