okay, the status on the backend refactorings is pretty good and i've got
all the major functionality fixed up and unit tested. i've also been
testing things out from the GUI along the way to make sure the
presentation layer was working as well. everything should be working
except for folders/bookmarks and possibly some referers stuff.
now for the more important part ...
as i have been reworking things i have slowly been warming up to Anil's
constant pleas that we provide some sort of transaction demarcation
available outside of the business layer. i still believe strongly that
we should attempt to hide all knowledge of persistence actions from the
presentation layer, however, based on the way that Hibernate wants us to
do things I think that providing a simple flush method may be more
appropriate than the strict boundaries that i originally proposed.
while this will require me to rollback a couple of the changes i have
made i still think that most of the work is applicable, notably that we
have removed the PersistenceStrategy and given more freedom to
persistence implementors, removed persistence specific methods from our
domain model (save() and remove()), and that we have removed the
extraneous transaction methods (begin(), setUser(), getUser(), and
rollback()) from being accessible to the presentation layer.
so, what i would propose is that we add a new method to the Roller
interface, flush(), which will trigger a database flush for any changes
that have happened within the current running transaction. all other
transaction operations (begin() and rollback()) are handled behind the
scenes by the persistence implementation. transactions are
automatically started when a Session (i.e. Request) begins. after any
flush occurs a new transaction begins to prepare for further changes.
if there is ever a problem caused by a flush then a rollback happens
automatically. so the work flow would look like this ...
incoming request
session begins, transaction begins
objects are queried for and updated
flush()
-- optionally make more changes and flush() again
response committed
at the end of the day this model places a greater emphasis on having a
properly structured domain model, which i believe is a good thing.
so, thoughts anyone? Anil, does this sound more like what you had in mind?
-- Allen
