Hi Ken, 1. My application is substantially complete and has many references to the class names e.g. Account. it seems I should have used the scheme Account(interface) & AccountImpl(class) in order to avoid breaking my application code references to Account, RIGHT?
I did a similar refactoring and took this approach. This makes sense as I don't really care if I am dealing with an interface or a concrete class. You do need to refactor your code to make sure you never new an Account though. My application either retrieves the object from the persistence layer or requests a factory to create it. 2. When casting objects from a collection, should I cast to the class name or proxy interface name? The interface. The proxy pattern uses delegation, so the proxy implements your interface and simply delegates the calls to the interface on to your real object which is materialized on demand. 3. Must I include the full hierarchy, including interfaces, in my repository.xml even though the interfaces are for dynamic proxies only? Following the naming convention used in (1.), I would map the interfaces as extents of the concrete class. This allows you to query for an Account and not have to query for an AccountImpl. 4. In the repository.xml, it seems that all superclass elements must be duplicated in each subclass? Is that correct? The repository does not support inheritance of descriptors, so yes you do need to map the superclass elements on each subclass. The inheritance of class descriptors is a feature that I would like to see added to the repository handler at some point in the future. I could greatly reduce the size of repository for large inheritance models. Thanks, -ken --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
