Robert- I re-read your message and I think I missed a key point in your question. See in-line....
--- Robert Ollila <[EMAIL PROTECTED]> wrote: > 1. The object model must be designed in a relational database type of > model > in order to later use JDO. For example, each class should have some ID > type > field, and the cardinality of the relationships may have to be defined > from > several perspectives within the java classes. In other words, objects > contained within objects may need to have references to the objects that > contain them depending on your database schema. I wouldn't normally do > this > if I was not going to use JDO. So, the bottom line is that JDO support > can > not just come as an afterthought for ANY object model - the XML schema > you > use must be designed accordingly. Any input on this ? (This is long, so bare with me. This hit a spot on my radar that seems to come up alot.) I need to be careful about this issue. People write applications in many ways. Some like to start at the object level, then build a database to support the object model. (I do this when possible) Others start at the database, and write an object model to support the database. It gets more complicated when you consider how the 'database' is being access. Nerd-vana occurs if you can limit access to the database to your specific object layer only. However, reality dictates that sometimes, you need to access the database directly. (Reports programs like Brio, etc) I bring that up since you described how the JDO view of the data 'requires' an interpatation of the data model that is different from your original view. This means that your original data model isn't meeting the needs that you have (could have?) in the object world. Thats usually a first sign of trouble. When this happens to me, I try to do the following: If you have the ability to re-model your context/domain in the object world, do that first. Make sure the model is consistant with your specific problem. Ignore JDO and the database, but just get an object model that is usuable. Second, pick a complicated use-case you may have, and double-check that your model works in that use-case. Then, if your satisfied, go down the path I described. (Put the model in an xml schema, generate the classes, etc) and flesh out the schema to completeness. Once thats down, and you have the generated classes, you can now map it to the database, generating a database to the needs of you in the object world. Ok, with that rambling, I'm ready to deal with the crux of the issue you have. Yes, JDO and XML support is secondary to the model. Period. They are implementations to help manipulate the model to the needs of the business. You need to build the model first that describes the problem domain, and then figure what tools help with the problem domain. Yet, as I say that, it conflicts with how I just described how I use the XML source generator and JDO layer. I build the model using the schema first, and then generate the class structure. In reality, this isn't exactly true. I prototype my model first. I create a working model that is just an object model, but I build the model using TogetherJ (Or rational Rose, or whatever) After working my initial thought-bugs out of this paper-model, I then picked up the XML schema. And here is the important part. In my case, the hierarchial nature of the XML world fits my model just fine, so I continued along that path. Had I needed to change my model to decompose it into an XML schema, then I'm SOL, and I need a different tool. This is why I said I had to be careful. This isn't a silver bullet. Its a tool. A good tool, but just a tool never-the-less. If it breaks the core model, then its the wrong tool. I'm not saying that if you can't model your entire system using XML Schema don't use the XML schema at all. Rather, I'm saying not to depend on it for the entire system like what I'm doing if you cannot use it for the entire system. I happen to be lucky enough where my model fits, and I can use the XML schema and generated classes in my entire project. That may not always be the case. When its not the case, use it only for when it fits. Otherwise, your just promoting the tool for the tool's sake, and not the principle that the tool was built on. There is a specific architectural pattern that fits each problem domain we work on. From what I do with JDO, it doesn't change my pattern, but provides an implementation to use the specific pattern. XML Schema has some restrictions only because of its hierarchial nature. These restrictions can benefit an object model, or be determental to it, and sometimes, that's hard to find out which it is until its in production and needs to be maintained. JDO is easier because Java is based on objects, and RDBMS (generally) isn't. JDO allows one to stay in the object world. XML source generator can help too, but its a more precarious fit if you use it to design your object model like I suggested. I guess the only real advice I have is this; "Use it if it works. Do not use it if it doesn't work." (Yeah, real helpful, eh? ;-) I'd normally say that this is just my $0.02 worth, but since it took abit to say, its my $0.04 worth. ;-) And I think I answered your second question, but let me know if what I said wasn't clear. ===== Virtually, | "Must you shout too?" Ned Wolpert | -Dante [EMAIL PROTECTED] | _________________/ "Who watches the watchmen?" 4e75 -Juvenal, 120 AD -- Place your commercial here -- fnord __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
