Simplicity is king in my book. I still think there's a fair amount of value in using Spring to define the transaction attributes for the middle-tier. Of course, I'm biased. ;-)
Matt On 4/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > 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 > >
