I've been evaluating TOPLink, too. For answers and a personal comment see below. Mark Volkmann wrote: > I've seen several messages discussing TOPLink on this list. I've been evaluating it > lately and have identified a number of restrictions it imposes on the way your Java > classes must be coded. I'm interested in hearing whether others have run into these > same restrictions. Am I off base on any of these? > 1) All object fields that are mapped to a database table column must either be public > or have both get and set methods that are public. There are many cases when a class > wishes to provide a get method but no set method because the field is read-only. This is only necessary with JDK 1.1. With JDK 1.2 TOPLink is able to access private attributes via the (enhanced) Reflection protocol. > 2) Methods that provide access to collections must return the collection object > (ex. a Vector) instead of an object such as an Enumeration of Iterator. > There are many cases when a class doesn't want to do this because it doesn't want > to allow callers to modify the collection. This is correct. Again, with JDK 1.2 this becomes irrelevant because the collection attributes can remain private. > 3) Every class on the "many end" of a one-to-many relationship must have a field > that holds a reference back to the "one end". There are many cases when it is > unnatural for that class to have knowledge of the other class. Even worse, if a > class can be referenced by collections in multiple other classes, it must hold a > reference back to each of them. That is really the most annoying problem. If you are willing to create a separate link table you can work around this problem by using a many-to-many mapping on the "one end" without mapping the backward direction. That worked in my test apps, but I'm not sure if it is officially supported. > 4) When using JDK 1.1, only Vector is supported for one-to-many mappings, > not Hashtable. JDK 1.2 must be used to utilize Hashtable and other collection > classes. Correct. Now let's move from the fact side to the opinion side: During the last months I have looked at nearly 10 different persistence products. They fall in two different categories: 1. based on EJB 2. not based on EJB If one is willing to take EJB as foundation for development *and* does not need very sophisticated mappings to legacy databases, he can choose between some good EJB server products. I won't recommend one of them because I didn't take a deep look into them. If one is not in the position to go for EJB, the choice becomes a lot more difficult. Each product has it's own share of disadvantages and one has to decide which are the most acceptable. As I said above, Your no. 3) is on top of my disadvantages list for TOPLink, too. Another problem on my list is their approach regarding Proxies for lazy read; that has also been discussed already on this mailing list. And there are some more minor points. IMHO these disadvantages should not dominate the opinion about the product, because it has a lot on its credit side, too. Just to mention a few: - it's the least intrusive product I have seen - very powerful UnitOfWork concept - the only product that can map references to interfaces and allows queries on interfaces - works with JDK 1.1 *and* JDK 1.2 - no native code - very flexible mapping allows to map even the most cumbersome database schemas The performance is comparable to the other non-EJB products. You take a performance hit compared to a tuned JDBC solution, but that hit was affordable at least in my tests. Summarized, in my experience TOPLink is a product that works reliable if You can live with its limitations, and that cannot be said for all persistence products on the market. My recommendations for the selection of a persistence product would be: - define your requirements (that's the most difficult step) - decide between EJB and non-EJB - compare about 3 products against your requirements before making a decision - don't expect the perfect product - don't exclude TOPLink based on the mailings on this list Wolf Siberski ------------------------------------------------------------- Wolf Siberski TUI Infotec GmbH OO Consultant Karl-Wiechert-Allee 23 mail: [EMAIL PROTECTED] D-30625 Hannover fax: +49-511-567-1301 Germany phone: +49-511-567-5317 http://www.tui.de =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
