Joerg Heinicke dijo: > Hello Bert, > > it seems we went exactly the same route this week.
Great! I think I takes me 1 or 2 months while understanding how to start all this puzzle and choicing between OJB and Hibernate and why + what if I am wrong and this cannot work at all, also waiting for a more functional Woody and Flow, and a couple of additional things, etc.! :-DD In fact, I am glad to see the "path" being opened in mid 2003 now is clear and other can use and improve the road. This was the main goal of OJB block and I like to see that it is useful to other people. Share the ideas with the community is great! > Maybe we should put together our efforts to get this thing working and to > help other people with a wiki page. I will love this! I am sad that I cannot had the time to do this. I need to tell I am newbie in OJB too. Maybe 1 or 2 days ahead in some cases, but this is nothing. Of course we are trying to improve our knowledge and will share it. In short, please write the wiki page and I promise to review it and improve it in case I know a little bit more. I will do it very glad. > I only don't have that time til beginning of March because there is > still an exam to be passed. So let me write a "short" mail about > my experiences. > > We have at least our own application running with OJB. We can retrieve > lists or single objects from the db and display them with Woody, we can > store them back and delete them. We only have still a problem with > object identity, I think there is an old bug in JDO implementation in OJB related to indetities. We fight with this problem 2 weeks with no results, then we decided to switch to PB implementation. But let the open door to rewrote the code when JDO will be avaliable. > so that storing does indeed create a new object in db, > but that's another problem we didn't have a closer look yesterday evening. > > We started also with OJB/JDO and had bad feelings when we saw that we > have to maintain at least two files (package.jdo, repository.xml) to get > it working. The reason for it is that JDO and OJB are two different > products, OJB provides only a plugin for Sun JDO at the moment, but both > must get their configuration. Though it's easy to write a stylesheet > that converts one format into the other I tried to use only JDO. While writing the code in Druid, I noted that repository.xml has far more info that the .jdo onces. In fact after querying on the OJB maillist I noted we don't need to put too much info inside the .jdo. AFAIK, the only need info in .jdo is the info that currently druid put on the .jdo files. > But JDO is just the API, the SPI must be provided by the database > vendor and as > there are probably not that much for a specific at the moment, you need > OJB. Then we found out that the JDO implementation has a performance > problem: Retrieving 20 rows out of 6.000 in a db leads to instantiation > of all 6.000 objects, they are filtered by JDO. That's not a problem of > OJB, it's just how Sun JDO works. So we were back nearly to the > beginning. Hmm.. switching between JDO->(PB|OTM|ODMG) is not too painfull. This in one of the best features of OJB at all. > We decided to go on with OJB (as it allows easy switch > between different persistence frameworks (JDO, ODMG, OTM, PB)), but used > the OTM. This one provides also object level transaction. > Now the application itself. I don't love the idea of accessing the > persistence layer from the flow/controller layer directly. We access it > only from the application layer to have obvious tiers. We have a > DAOFactory that returns DAOs (e.g. either JDO or OTM), the > implementation of the persistence framework access is abstracted. We choosed to have DAO classes with static methods, that way we don't need to create too many DAO objects. Between Flow and DAO classes fly the Beans. Some of them are BeanList. They are easily passed to the cforms using the framework binding. I am not sure if this is the best approach, but it works. I will be glad if we can comment about what are the pros and the cons of Joerg approach vs. this approach. I am not a Java or OO guru. Comments are very welcome. > In > theory we can switch to Castor, Hibernate or what else without touching > the application layer. Can you explain what is the application layer? I am confused here. Is the application layer the view in the MVC paradigm? > Each object specific DAO will provide different > methods for retrieving, storing, deleting etc. As the layers below the > flow layer are no Avalon components and not in relation to Cocoon, but > "Plain Old Java" we kicked out Cocoon OJB block completely and just use > OJB. If this was a good decision we will see. I thought to do this too. In fact the first experiment was using directly OJB in Cocoon: http://wiki.cocoondev.org/Wiki.jsp?page=OJBWithJDO Later, I thought that the best approach was to use a common factory for all the servlet instead of using OJB directly. > But it won't be that difficult to switch the datasource back to > Avalon/Cocoon in OJB properties file. AFAIK, using OJB as an avalon component is better from an architectural view because it follow the same approach as the other components. AFAIK, we can also use other components outside Avalon schema, but this is rather not desired. > BTW, we package all classes, configuration files and so on into our > application JAR, deploy it in WEB-INF/lib and it works without any > problem. I use 2 jar approach, one for beans and other for DAO. BTW, I prefer to call them "Handlers" because they are more or less oriented to handle data from/to CForms forms. Instead of writing the code in Flow files, I prefer to use Flow just as a true controller (shorter files). It does not do the work just decide what to do with the recieved request. To me Flow is just the controller that recieve request and decides where to send the beans to be processed. I am open to discuss this in more detail because it will be great to find the best approach based on all our experiences. We are learning here and will be fine to share our knowledges. >From my POV, is a very important note that maybe we don't need avalon based components in OJB block. But I think we need the block to show users how this technology can be easily used inside Cocoon. AFAIK Cocoon is: "web glue for your web application development needs" in this way the OJB block is a key component for DB integration. :-D Best Regards, Antonio Gallardo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
