Hello Ken, > -----Original Message----- > From: Ken Brewer [mailto:[EMAIL PROTECTED]
[..] > > > Of course I have to cast to Account though. > > > > I do not understand that. Where do you do that cast? > > It is an upcast, isn't it? Then it is never needed in Java. > > When retrieving a collection element. That makes sense, now > that I typed it, > because the real class is a dynamic proxy not AccountImpl. I understand. You are right, and it is not an upcast. [...] > > I suggest that the fields' types are interfaces. That is good > > practice in Java anyway, and you will need it do use the proxy > > feature. If you expect not to use any other implementation > > of that interface with OJB, there is no need to bother the > > repository_user.xml with it, so I recommend not to mention > > the interface there. > > That's what I have in my classes. So you suggest always querying for > implementation classes since OJB will not know of the > interfaces? That also > means that collection and reference descriptors must point to > AccountImpl instead of Account right? Right. > > > found. All of these methods seem to require my client code to use > > > AccountImpl in some places but Account in others. Is that right? > > > > I do not understand that. Where in your application > > do you need AccountImpl? > > In queries since OJB doesn't know of interfaces e.g. Account. Oh yes, the queries. I had forgotten about those. In our application, we have encapsulated the OJB queries, too, and we use Strings to specify the class names there. This way, the application never uses the OJB classes. If you want to keep the option of switching to another O/R-mapper, you have to do that anyway. But I would not say that everybody should do it that way. [..] > OK. My app is also currently programmed against interfaces and gets > instances with Factories. With this approach, I've found that I cannot > mention the interface an OJB query. Someone else suggested I add the > interfaces to the repository so I could query for them. I > fell for it but it > seems that approach requires a complete interface hierarchy in the > repository matching the implementation hierarchy. I mean > complete with all > field, reference, and collection descriptors. It seems that > this only gains > one the ability to use interfaces in queries like: > > Query query = QueryFactory.newQuery(Account.class,crit); > > instead of implementation classes like: > > Query query = QueryFactory.newQuery(AccountImpl.class,crit); o.k., I see your point. Yes, if you want the application not to use AccountImpl and you do not want to encapsulate the queries, then OJB has to know about the interface in some way, i.e., it has to be in the repository_user.xml. In that case, I recommend that your reference-descriptors nevertheless use AccountImpl as the class. Olli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
