Allen Gilliland wrote:
just a reminder, silence == consent. i am planning to move forward with
development on this.
-- Allen
I added some comments to the proposal page (Design Overview Section 2).
There are some considerations you really should take into account if you
move the transaction demarcation into the managers.
I understand your goals, and I'd just urge taking a couple of
precautions. There are some dangerous curves on that road. You might
want to do the development in a branch and integrate back when you've
got the kinks out. You might also want to talk with some folks whose
knowledge of transaction management you trust.
Finally, (though I know I'm unlikely to convince you), you might want to
consider an alternate strategy that removes explicit transaction
demarcation calls from the app layer, but rather than putting them into
the manager layer, puts them at a small number of well-defined points in
the request dispatch infrastructure (above/outside the app layer proper
rather than below it). I think this is closer to the existing Roller
design (before such calls proliferated into the present mess).
Matt's suggestion of using Spring's declarative demarcation is another
good alternative.
My number one suggestion is that no matter which way you go, pick one of
the known and commonly used patterns and adopt it, and depending on the
choice you may find existing infrastructure that supports it that you
can also adopt.
--a.
On Mon, 2006-03-06 at 13:25, Allen Gilliland wrote:
Okay, here is a more flushed out proposal of what I think should be done ...
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_BackendRefactorings
Note that the driving force behind these changes is to 1) prevent direct access
to the PersistenceStrategy from outside the business layer and 2) limit
persistence logic (like transaction details) to the business layer.
I think those are very appropriate goals to have for the architecture of our
code.
-- Allen
