"Volkmann, Mark" 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? I am no fan of TOPLink, but let me give you some insight into how we handled these situations. > 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. In any case where our domain objects didn't naturally follow the restrictions TOPLink imposes, we created methods with a "DB" suffix (we wish that we had used a prefix, instead) that were to be called only by TOPLink. We marked these methods with the "@deprecated" tag, so their use would show up in a compile (TOPLink uses reflection, so you won't get the warnings from it). This also must be done if you're lazily initializing properties on your objects (because they're JavaBeans, or something). We created DB methods that made sure the objects are not empty when mapping occurs; if the are, we return null. > 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. We would again create DB methods for these cases. > 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. Yes, this is very unfortunate. This will really haunt you if you are passing these objects over the wire; the object in the back pointer is not cleared, so it will be serialized, too. You can try either nulling out the references yourself, or marking the back references as "transient". > 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. Yeah. -Kevin
begin:vcard n:Lewis;Kevin x-mozilla-html:TRUE url:http://www.axyssolutions.com/ org:Axys Solutions adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Technical Partner end:vcard
