Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: More 'code'ification, sneaking up on a markup problem too

...

Note that it might be preferable to have a more generic implementation of the ItemDAO interface that supports both PostgreSQL and Oracle, but given that one motivation for adopting DAOs is to remove db-specificities from the code making it easier to port, I thought it was sensible to start with just PostgreSQL. Eventually, it ought to be possible to drop in ItemDAOHibernate (etc) implementations that make db portability far easier.

...

Basic implementation of the Item object. This class has been stripped down to remove all contact with the database, including (but not limited to) contstructors, factory methods, update(), delete(), find(), etc. I haven't decided exactly how the Item API will look, but it will probably be much the same as before, only with any of the aforementioned methods. Another key difference is that it will have actual Java objects as member variables instead of pulling everything out of a TableRow.

org.dspace.content.proxy.ItemProxy

This will be a fairly simple proxy implementation. Specifically, it will be closest to being a virtual proxy, in that it will appear to be a regular Item object, but will have a slightly smarter implementation (not loading metadata until requested, keeping track of what has changed to make updates more efficient etc).

...

This is a fairly straightforward implementation of the above interface. As much as possible, code from the original Item class will be used. For instance, this is how getItems() is implemented:

...